Revised "MCE semantics"

Fri Nov 16 02:42:47 CET 2012

I am confused.  I have always believed that implementations are required
to detect mismtaches.  If some MCE processor reports nothing upon
encountering mismatches, what is the point of MCE?

The current wording mandates reporting and prohibits
continuation of normal processing.  We might want to allow continuation
of normal processing.  But I oppose to allowing the MCE processor to
silently ignore mismatches.

Regards,
Makoto

2012/11/16 John Haug <johnhaug at exchange.microsoft.com>:
>> The MCE processor is required to report all mismatches.
> I think that leaves the Wiki text in effectively the same state.  I believe Francis' point wasn't so much about use of the term "error" as much as the explicit requirement that an implementation report errors/mismatches.  I believe he's right that we had earlier decided to simply define what an error/mismatch was and not require any behavior about how to handle them.  That
leaves open a number of possibilities, such as reporting the error,
failing hard, trying to recover the document content, etc. and avoids
creating ambiguities such as whether a consumer must stop processing
and report an error when it's encountered and whether it may continue.
 I think leaving the behavior up to the implementer is the best
approach as long as we have clearly defined what is an "error", "error
condition", "mismatch" or whatever we ultimately call it.
>
> In X.4 (ExtensionElements), the current ext elements in Part 1/Part 4 are listed.  I think what we actually want here is the extLst elements.  Those are the OPC extension elements and ext is just a regular Part 1/Part 4 element that goes inside it.  This is the list of extLst I come up with:
> - http://purl.oclc.org/ooxml/spreadsheetml/main
> - http://purl.oclc.org/ooxml/presentationml/main
> - http://purl.oclc.org/ooxml/drawingml/main
>  - http://purl.oclc.org/ooxml/drawingml/chart
>
> John
>
> -----Original Message-----
> From: eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] On Behalf Of MURATA Makoto
> Sent: Thursday, November 15, 2012 3:29 PM
> To: SC34
> Subject: Re: Revised "MCE semantics"
>
> Francis and Caroline,
>
> Thank you very much for proofreading the semantics wiki.  I owe you many thanks.
>
> I will read the revised wiki page, but here is my response to Francis' comments on "error".
>
> I deleted all the word "error".  Syntax errors are removed.
> Mismatch errors are now simply mismatches.  The MCE processor is required to report all mismatches.  No statements about errors any more.
>
> But is there is an exception?  Are non-ignorable elements as children of AlternateContent elements required to be detected?  Feedbacks from Ecma arre very welcome.
>
> Regards,
> Makoto
>
> 2012/11/16 Francis Cave <francis at franciscave.com>:
>> My responses to Caroline's comments are interspersed below.
>>
>> I have revised the first paragraph of X.5 to be more consistent with
>> the text specifying other attributes.
>>
>> I have changed "specify" to "have", when specifying whether or not a
>> particular element may "have" attributes. This is purely for
>> consistency. If "specify" is a better word, we should use it throughout, but I think "have"
>> is more easily understood. I have similarly changed some instances of "at"
>> to "of" when specifying an attribute "of" an element.
>>
>> I have made some other minor editorial changes.
>>
>> I am not convinced that the terms "error", "mismatch error" or "syntax
>> error" need to be defined. I thought we had agreed that we wouldn't
>> identify non-conformant documents as containing "errors" as such,
>> leaving it to implementations to decide to how to handle specific
>> kinds of non-conformance in documents. Nevertheless, I agree that we
>> should define conformance in terms of "syntactic conformance" and
>> "semantic conformance", the absence of the latter being what we mean
>> by a "mismatch". Syntactic conformance/non-conformance is spelt out in
>> X.1. Semantic conformance/non-conformance is spelt out in Y.1, but
>> currently in terms of "mismatch errors".
>>
>> I am also not convinced that we should be specifying what the MCE
>> processor should do when it encounters non-conformance of any kind.
>> Should the text really require that errors be reported? I would prefer
>> it if we simply make it clear what is and is non conformant and leave
>> it to implementers to decide what to do when certain kinds of non-conformance are encountered.
>>
>> If we wish to make reporting a normative requirement, would it not be
>> better just to say something like: "An MCE processor shall report all
>> instances of non-conformance to this specification, whether syntactic
>> or semantic"? I'm not convinced that this is a good idea, but it would
>> avoid the necessity to go into detail of how implementations should
>> behave when encountering non-conformant syntax or semantic mismatches.
>>
>> I have highlighted in yellow a sentence in X.1 that I believe should
>> be deleted, if the above argument is accepted. I have also highlighted
>> comments that I've added in Clause Y that relate to the above argument.
>>
>> I have deleted a duplicate second paragraph in Y.1 and made some minor
>> editorial corrections elsewhere in Y.
>>
>> Francis
>>
>>
>>
>>> -----Original Message-----
>>> From: Arms, Caroline [mailto:caar at loc.gov]
>>> Sent: 15 November 2012 15:10
>>> To: francis at franciscave.com; 'SC34'
>>> Subject: RE: Revised "MCE semantics"
>>>
>>> Some copy-ediiting for the X section:
>>>
>>> Definitions
>>> Question -- where does the binding of prefixes to namespaces happen?
>>> Is there reason to be explicit about this.
>>
>> I don't think so. We are using the term "namespace" in the normal XML sense.
>> Part 3 references "Namespaces in XML" normatively, so we shouldn't say
>> anything about how namespace prefixes are bound to namespace URIs,
>> because this is defined in the XML Namespaces referenced specification.
>>
>>> X.3
>>> "An ProcessContent"  should be"A ProcessContent"
>>
>> Corrected on the wiki text.
>>
>>> "ExtensionElements" should be "ProcessContent"
>>
>> Corrected in the wiki text.
>>
>>> I would insert an article in "declared as process content name pair"
>>> to yield "declared as a process content name pair"
>>
>> I agree. Corrected in the wiki text.
>>
>>> X.4
>>> I would insert an article in "declared as extension element name pair"
>>> to yield "declared as an extension element name pair"
>>
>> I agree. Corrected in the wiki text.
>>
>>> "or its ancestor.t." should perhaps be "or any ancestor element."
>>
>> I agree, except that, for clarity, I would insert "of", i.e. "or of
>> any ancestor element." Corrected in the wiki text.
>>
>>> To make the extension element name pairs appear like pairs, should
>>> there be  a separator between "}" and "ext"?
>>
>> I think this is a widely accepted notation for representing expanded
>> qualified names.
>>
>>> In the Note, the term "markup specification" might benefit from
>>> qualification or an example to add clarity.
>>
>> I think this is an editor's note, not intended to be a Note in the
>> revised text of Part 3. It is a reminder that, if the
>> ExtensionElements attribute were added to Part 3, Part 1 would need to
>> be revised to explicitly prohibit its use.
>>
>>> X.5
>>> "declared as must-understood" should be "declared as must-be-
>>> understood" or "declared as must-understand"
>>
>> I think that it would be better to stick to a single term "must understand".
>> I would therefore propose instead "declared as a must-understand namespace".
>> I have altered the wiki text accordingly. There is probably a case for
>> adding "must-understand namespace" to the Definitions.
>>
>>> X.6
>>> Missing "in" in first sentence: "element the Markup Compatibility
>>> namespace" should be "element in the Markup Compatibility namespace"
>>
>> Agreed. Corrected in the wiki text. I similarly feel that "attribute
>> of the ... namespace" should be "attribute in the ... namespace"
>> throughout, and have revised the wiki text accordingly.
>>
>>> X.7
>>> Missing "in" in first sentence: "element the Markup Compatibility
>>> namespace" should be "element in the Markup Compatibility namespace"
>>
>> Agreed. Corrected in the wiki text.
>>
>>> Is "of the local part" correct in 2nd para?
>>
>> No. I have changed this to "with local name".
>>
>>> Missing "q" [ or "unq"] in "ualified"
>>
>> Agreed. Corrected in the wiki text.
>>
>>> X.8
>>> Missing "in" in first sentence: "element the Markup Compatibility
>>> namespace" should be "element in the Markup Compatibility namespace"
>>
>> Agreed. Corrected in the wiki text.
>>
>>> Missing "e" in "lement"
>>
>> Corrected in the wiki text.
>>
>>>    Hope this helps.  I'll get to Y later.
>>>    Caroline
>>>
>>>
>>> Caroline Arms
>>> Library of Congress Contractor
>>> Co-compiler of Sustainability of Digital Formats resource
>>> http://www.digitalpreservation.gov/formats/
>>>
>>> ** Views expressed are personal and not necessarily those of the
>>> institution ** ________________________________________
>>> From: Francis Cave [francis at franciscave.com]
>>> Sent: Saturday, November 03, 2012 7:07 AM
>>> To: 'SC34'
>>> Subject: RE: Revised "MCE semantics"
>>>
>>> I'll take a look after the weekend.
>>>
>>> Regards,
>>>
>>> Francis
>>>
>>>
>>>
>>>
>>> > -----Original Message-----
>>> > From: eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] On Behalf Of
>>> MURATA
>>> > Makoto
>>> > Sent: 03 November 2012 09:59
>>> > To: SC34
>>> > Subject: Revised "MCE semantics"
>>> >
>>> > I removed all striked-out text, incorporated changes agreed in
>>> London,
>>> > and further incorporated some changes, which I think are necessary.
>>> >
>>> > I would welcome comments or even rewrite by WG4 members.
>>> >
>>> > https://www.assembla.com/spaces/IS29500/wiki/Semantics_of_MCE
>>> >
>>> > Regards,
>>> > Makoto
>>
>
>
>
> --
>
> Praying for the victims of the Japan Tohoku earthquake
>
> Makoto

-- 

Praying for the victims of the Japan Tohoku earthquake

Makoto