Revised "MCE semantics"

Francis Cave francis at franciscave.com
Thu Nov 15 17:57:24 CET 2012


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



More information about the sc34wg4 mailing list