Proposed text for Clause 9

Thu Aug 22 17:45:38 CEST 2013

Sorry, Murata-san, I should have read the current working draft more
carefully. 

So, the behaviour of MCE processors with respect to extension elements is
currently defined as part of the processing model in Clause 9. If we accept
that ALL applications of MCE must handle extension elements as currently
specified in Clause 9, this is the right place to specify such normative
behaviour. If, on the other hand, we can agree that SOME applications of MCE
(not OOXML) might wish to specify different behaviours for MCE processors
with respect to extension elements, we either have to remove such normative
requirements from Clause 9, or make it clear that they are not mandatory but
are recommended as likely best practice, or weaken them further by including
them purely as examples of how MCE processors might behave. 

As I have already stated, my main concern is that, if we are revising Part 3
so that MCE can be applied in markup specifications other than OOXML, we
should think carefully about which behaviours need to be normative for all
MCE processors, regardless of MCE application, and which should be specified
by the application. Clearly it makes sense to specify normatively all
behaviours with respect to MCE constructs, i.e. constructs that are
represented by elements and attributes with names in the MCE namespace. But
I don't think this necessarily applies to extension elements - which are,
after all, supposed to be "application-defined". I think it can be argued
that if they are application-defined, the way they should be handled by MCE
processors should also be application-defined. Otherwise, why not define an
element in the MCE namespace called 'mce:extension-element' (or 'mce:ext',
if you prefer) and leave it at that? I know that OOXML hasn't done that, and
maybe we feel that it should have done, but it didn't, and therefore the
question has arisen - in my mind, at least.

Kind regards,

Francis

From: eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] On Behalf Of MURATA
Makoto
Sent: 22 August 2013 16:19
To: Francis Cave
Cc: SC 34/WG 4 mailing list
Subject: Re: Proposed text for Clause 9

2013/8/13 Francis Cave <francis at franciscave.com>

Murata-san

I understand the distinction between MCE processors and markup consumers.

> To me, markup consumers and MCE processors are very different.
> Requirements on MCE processors have to be very clear.  Their behaviours
are

> complet[el]y predictable.  But requirements on markup consumers are much
more
> predictable.

I think you mean that the requirements on markup consumers are much LESS
predictable.

Right.

But if the behaviours of MCE processors are completely predictable, should
these not be specified normatively somewhere? If the behaviour of an MCE
processor with respect to extension elements must be completely predictable,
this behaviour must be specified normatively. Where is it to be specified?
Either in the MCE spec or in the markup spec.

At present, the behaviour of MCE processors for application-defined 

extension elements is normative defined in several places:

  - the 4th bullet in the 1st itemized list in Step 1 in Clause 9

  - the 3rd bullet in the 2nd itemized list in Step 1 in Clause 9
  - the 4rd bullet in the 3rd itemized list in Step 1 in Clause 9
  - the 3rd bullet in the 1st itemized list in Step 2 in Clause 9
  - the 2nd bullet in the 2nd itemized list in Step 2 in Clause 9

  - The 1st, 2nd, and 3rd paragraphs in Step 4 in Clause 9

Regards,

Makoto

I think that my confusion is between the specification of extension elements
(in the markup spec) and the specification of MCE processor behaviour (in
the MCE spec). If we can completely specify MCE processor behaviour with
respect to extension elements, this should be done normatively in the MCE
spec. If we cannot - i.e. it depends upon how the extension elements are
specified in the markup spec - we cannot say anything normative about it in
the MCE spec and we probably shouldn't make too many assumptions about it.

Kind regards,

Francis

> -----Original Message-----
> From: eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] On Behalf Of MURATA
Makoto

> Sent: 13 August 2013 13:11
> To: SC 34/WG 4 mailing list
> Subject: Re: Proposed text for Clause 9
>
> Francis,
>
> Perhaps, the problem is the ambiguity in our terminology:
> markup consumer , MCE processor, and application program.
> We might want to make this point clear in Clause 7.
>
> > Your second paragraph says:
> >
> > "If an MCE processor is configured to recognise extension elements, it
> > preserves them together with their attributes and contents."
> >
> > I think what you are saying is that an MCE processor that is
> > configured to recognise extension elements will ALWAYS preserve them.
> > In other words,
>
> Exactly.  But I am talking about the MCE processor.  I am not talking
about
> markup consumers.
>
> > "recognise" in this context means "preserve".
>
> Well, I meant that the markup configuration, which is a set of expanded
names,
> contain the expanded names of application-defined extension elements.
>
> > If this is ALWAYS the case,
> > that sounds to me like a normative provision. If it is up to the
> > application to specify this (as I thought we had agreed), it may not
> > always be the case, in which we should not imply that in the MCE spec.
>
> To me, markup consumers and MCE processors are very different.
> Requirements on MCE processors have to be very clear.  Their behaviours
are
> complety predictable.  But requirements on markup consumers are much more
> predictable.
>
> Regards,
> Makoto
>
> >
> > Kind regards,
> >
> > Francis
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] On Behalf Of
> >> MURATA
> > Makoto
> >> Sent: 13 August 2013 11:12
> >> To: SC34
> >> Subject: Re: Proposed text for Clause 9
> >>
> >> Francis,
> >>
> >> > 1. Your proposed text (expecially the first sentence of the second
> >> > paragraph, and the final paragraph) defines an extension element
> >> > somewhat more narrowly than I had proposed in my draft text. Yours
> >> > is closer to what
> >>
> >> I rather think that your wording states too much about application
> > programs.
> >> I think that we should limit our concern to behaviours of MCE
> >> processors
> > and
> >> try to avoid describing behaviours of application programs.
> >> MCE processors simply pass application defined extension elements to
> >> application programs.  The behaviours of MCE processors have to be
> >> very
> > clear
> >> for interoperability.
> >>
> >> > is currently in OOXML, which may be a good thing (it shouldn't
> >> > break any OOXML implementations), but I still wonder whether the
> >> > MCE spec should be quite so proscriptive about the processing of
> >> > extension elements or should instead leave it to the markup
> >> > specification to define how MCE processors should handle extension
> >> > elements in each specific case. Putting it another way, your
> >> > proposed Clause 9 seems to be saying something normative about the
> >> > processing of extension elements, although you have made it clear
> >> > in the Clause heading that the
> >> Clause is informative.
> >>
> >> My 2nd para may look normative at a first glance, but it is not.  It
> >> just gives a high-level overview without providing details.  Details
> >> are
> > provided
> >> in the itemized lists in Steps 1 and 2.
> >>
> >> >
> >> > 2. At the end of the second paragraph you have a cross-reference to
> >> > "Clause 9". This is self-referential, so clearly wrong. What is
meant?
> >>
> >>
> >> Oops.  Clause 10 Semantic Definitions and Reference Processing Model.
> >>
> >> Regards,
> >> Makoto
> >>
> >> > Kind regards,
> >> >
> >> > Francis
> >> >
> >> >
> >> >
> >> >> -----Original Message-----
> >> >> From: eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] On Behalf Of
> >> >> MURATA
> >> > Makoto
> >> >> Sent: 13 August 2013 10:11
> >> >> To: SC34
> >> >> Subject: Proposed text for Clause 9
> >> >>
> >> >> Dear colleagues,
> >> >>
> >> >> Here is a proposed rewrite of Clause 9.  It is based on Francis'
> >> >> wording
> >> > but
> >> >> has been modified and further expanded by two examples.  Thanks. >
> >> > Francis.
> >> >>
> >> >> Regards,
> >> >> Makoto
> >> >>
> >> > -------------------------------------------------------------------
> >> > ---
> >> > ------
> >> > -
> >> >>
> >> >> 9. Extension elements defined by a markup specification
> >> >> (informative)
> >> >>
> >> >> A markup specification that uses Markup Compatibility elements and
> >> > attributes
> >> >> to allow extensions in namespaces other than those defined by the
> >> >> markup specification may also define one or more specific
> >> >> extension elements in
> >> > the
> >> >> namespaces that it defines. [Note: If the markup specification
> >> >> includes a schema, any extension elements would normally be
> >> >> constrained by the schema
> >> > to
> >> >> occur only in specific markup contexts. end note].
> >> >>
> >> >> If an MCE processor is configured to recognise extension elements,
> >> >> it preserves them together with their attributes and contents.
> >> >> See Clause 9
> >> > for
> >> >> details.
> >> >>
> >> >>
> >> >> [Example:
> >> >>
> >> >>
> >> > https://subversion.assembla.com/svn/IS29500/trunk/Part3/TestData/Ex
> >> > ten
> >> > sionEl
> >> > em
> >> >> ents/example1.xml
> >> >>
> >> >> In this example, the e1:foo element contains the unknown:foo
element.
> >> >> Suppose that a markup configuration contains an expanded name
> >> >> ("http://www.example.com/e1", "foo") and that an application
> >> >> configuration does not contain "http://www.example.com/unknown".
> >> >> Then, the element e1:foo is an application-defined extension
element.
> >> >> Although the unknown:foo element does not belong to an understood
> >> >> or
> >> > ignorable
> >> >> namespace, the MCE processor preserves it and does not report any
> > errors.
> >> > end
> >> >> example]
> >> >>
> >> >> [Example:
> >> >>
> >> >>
> >> > https://subversion.assembla.com/svn/IS29500/trunk/Part3/TestData/Ex
> >> > ten
> >> > sionEl
> >> > em
> >> >> ents/example2.xml
> >> >>
> >> >> In this example, Markup Compatibility elements and attributes
> >> >> occur within
> >> > the
> >> >> extensionElement element, which is the only child of the root
> >> >> element
> >> > example.
> >> >> Suppose that a markup configuration contains an expanded name
> >> >> ("http://www.example.com/e1", "extensionElement").
> >> >> Then, the MCE processor preserves the extensionElement element.
> >> >> Therefore, MCE elements and attributes within it, namely
> >> > mce:Ignorable="i1",
> >> >> mce:ProcessContent="i1:bar1", mce:MustUnderstand="e1",
> >> > mce:AlternateConent,
> >> >> mce:Choice, and mce:Fallback, appear in the output document.  end
> >> >> example]
> >> >>
> >> >> After receiving the output of an MCE processor, application
> >> >> programs may further invoke an MCE processor to handle Markup
> >> >> Compatibility elements
> >> > and
> >> >> attributes within extension elements.
> >> >
> >>
> >>
> >>
> >> --
> >>
> >> Praying for the victims of the Japan Tohoku earthquake
> >>
> >> Makoto
> >
>
>
>
> --
>
> Praying for the victims of the Japan Tohoku earthquake
>
> Makoto

-- 

Praying for the victims of the Japan Tohoku earthquake

Makoto 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20130822/57745405/attachment-0001.html>