Proposed text for Clause 9

MURATA Makoto eb2m-mrt at asahi-net.or.jp
Wed Aug 21 13:12:25 CEST 2013 

Nobody has responded to my latest mail.  Perhaps, people need
full text.  Let me try.

Regards,
Makoto


2013/8/16 MURATA Makoto <eb2m-mrt at asahi-net.or.jp>

> John and Francis,
>
> As I said during the teleconf, I think that the confusion stems
> from non-clear separation of MCE processors and applications
> in the current text.  I am trying to clarify requirements on
> MCE processors.  Meanwhile Francis is trying to allow
> some office suites NOT to preserve ext elements.  (I agree
> that such office suites should not be prohibited by 29500.)
>
> Here is what I would like to propose.
>
> Principles
>
> - MCE processors are crucial in MCE, just like XML processors are
>   crucial in XML.  Clearly define requirements on MCE processors.
>
> - Consuming applications are built on top of MCE processors at least
>   conceptually.  There should be no requirements on consuming
>   applications.  Nothing prevents some office suite from discarding
>   ext elements in SML.
>
>
> General
>
> - The term "markup consumer" is considered misleading, since it makes it
>   difficult for us to separate MCE processors and consuming
>   applications.
>
> - Drop "markup consumer" and "markup producer" from the Terms
>   and Definitions clause.
>
> - Reformulate normative sentences on "markup consumer"
>   as those on "MCE processor".
>
> - Use "consuming application" and "producing application" in
>   informative statements and nowhere else.  These are usual noun
>   phrases rather than terms defined in the Terms and Definitions
>   clause.  These phrases are used only for providing a high-level
>   overview.
>
> - Unless there are mismatches or errors, MCE processors emit
>   output documents, as specified in the revised Part 3.  We require
>   that MCE processors copy application-defined elements (together
>   with their attributes and contents) from the input to the output.
>
>
> If people agree with the above approach, I will prepare replacement
> text.
>
> Regards,
> Makoto
>
>
> 2013/8/16 John Haug <johnhaug at exchange.microsoft.com>
>
>> I believe the current text implies that the MCE processor does nothing
>> with them by saying that MCE processing is suspended within them - that
>> it's just a pass-through as Murata-san mentioned.  Whether they're
>> preserved in the output document it out of scope for that pass of the MCE
>> processor.  I believe thhis also matches our implementation - the MCE
>> processor just hands them up to the calling markup consumer / application
>> program, which decides whether to crack them open, I believe by handing
>> them to a MCE processor (if they're understood) or ignore them (if they're
>> not understood) and choosing whether to discard or retain them for the next
>> file save.
>>
>> At least, that's always been m understanding.
>>
>> John
>>
>> -----Original Message-----
>> From: Francis Cave [mailto:francis at franciscave.com]
>> Sent: Thursday, August 15, 2013 1:53 PM
>> To: 'SC 34/WG 4 mailing list'
>> Subject: RE: Proposed text for Clause 9
>>
>> John
>>
>> The intent of my original text (which, you're right, I didn't copy to the
>> WG list - apologies about that) was to avoid saying anything normative
>> about the behaviour of MCE processors with respect to extension elements,
>> as I felt it is a feature of OOXML as a markup spec that extension elements
>> should be untouched by MCE processors and not necessarily a required
>> feature of all MCE applications. I think that Murata-san has convinced me -
>> almost - that MCE processors should always leave extension elements
>> untouched, so that the application software part of the markup consumer can
>> determine what to do with extension elements that it does or does not
>> understand.
>>
>> Kind regards,
>>
>> Francis
>>
>>
>>
>>
>> > -----Original Message-----
>> > From: John Haug [mailto:johnhaug at exchange.microsoft.com]
>> > Sent: 15 August 2013 21:34
>> > To: 'SC 34/WG 4 mailing list'
>> > Subject: RE: Proposed text for Clause 9
>> >
>> > May I risk wading into this?  I think I understand Murata-san's points
>> > and
>> I
>> > think the general direction of his text is OK.  But I also think
>> > Francis
>> has a
>> > point about the way the language is used.
>> >
>> > Re: the second paragraph:
>> > I believe it ought not mention preservation, since that is an optional
>> > function of the markup consumer.  Murata-san pointed out that "MCE
>> processors
>> > simply pass application defined extension elements to application
>> programs"
>> > which is correct.  But I agree with Francis that the language of the
>> second
>> > paragraph sounds like "extension elements shall be preserved in the
>> > output document".  May I suggest that the second paragraph be reformed
>> > to simply point to section 10 for rules about how MCE processors
>> > handle extension elements?
>> >
>> > Re: Murata-san's follow-up comment:
>> >       > "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 that means the point of the second paragraph is to state the markup
>> > configuration remains unchanged (not sure if that is the point), then
>> > I'd suggest it's not necessary to state that since there is no
>> > indication in
>> the
>> > text that the markup configuration would ever change.
>> >
>> > Re: the last paragraph:
>> > I suggest we make that a Note.  It's good clarifying information worth
>> making
>> > clear that we consider it normal behavior.  Even though the whole
>> > clause 9
>> is
>> > informative, the statement is about something outside the scope of
>> specifying
>> > an MCE processor and I think it would make the intent that it's
>> > ancillary information more clear by making it an explicit Note.
>> >
>> > The only thing I can't evaluate is Francis' statement " Your proposed
>> > text
>> ...
>> > defines an extension element somewhat more narrowly than I had
>> > proposed in
>> my
>> > draft text".  I don't know what original draft text is referred to here.
>> It
>> > looks like Murata-san's text (and the relevant bits of clause 10)
>> > mirrors
>> what
>> > is specified in the existing Part 3.
>> >
>> > John
>> >
>> >
>> > -----Original Message-----
>> > From: Francis Cave [mailto:francis at franciscave.com]
>> > Sent: Tuesday, August 13, 2013 5:56 AM
>> > To: 'SC 34/WG 4 mailing list'
>> > Subject: RE: Proposed text for Clause 9
>> >
>> > 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.
>> >
>> > 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.
>> >
>> > 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/TestDat
>> > > >> > a/
>> > > >> > 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/TestDat
>> > > >> > a/
>> > > >> > 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
>



-- 

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/20130821/0a4c4707/attachment-0001.html>

More information about the sc34wg4 mailing list