Revised "MCE semantics"

[MURATA Makoto]

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