RE: Sketch of the MCE processing model (was DR 09-0315 — MCE: Preprocessing Model)
Chris Rae
Chris.Rae at microsoft.com
Wed Sep 14 23:19:55 CEST 2011
Hi Murata-san - I've circulated this internally and I have some further feedback.
Re. Step 1: Is the set of known/unknown namespaces to be fixed before MCE processing? I'm guessing it is, but wanted to check.
Re. Step 2: This step needs some more context. If the MCE processing state is currently Normal, then copying the ancestor state is correct. If the MCE processing state is currently Ignoring, the ancestor state needs to overwrite any existing state. In other words, if we Ignore an element, that whole element tree is Ignored, not just that Element (unless that element is ProcessContents). For example, assuming namespace "yes" is understood, "no" is not understood:
<no:a Ignorable="no">
<yes:a Ignorable="yes" />
</no:a>
With the current proposal, the result will be the yes:a element, when it should really be empty.
Re. Step 3: What is meant by "stop normal processing"? Is it the same as ignoring an element?
Re. Step 4 - I believe the second condition is the reverse. The element is replaced by its contents if the QE name *does* match one of the ProcessContent elements. If it doesn't match, the whole element tree should be skipped with no further processing.
Re. Step 6 - This step should happen in parallel with Step 5. MustUnderstand should be processed on all AC/Choice elements. For example:
<AC>
<Choice Requires="yes" />
<Fallback MustUnderstand="no" />
</AC>
This should yield an error, which means MustUnderstand must be processed while Step 5 is occuring.
One final thing - I'm not sure where exactly this ought to go, but there are restrictions on the various MCE constructs that probably ought to be validated somewhere - for example, alternate content blocks may not have children other than "choice" and "fallback" and attributes other than "xmlns" and "ignored" - not sure how exactly these are best represented in the standard. Perhaps some sort of simple base schema for MCE itself?
Let's discuss further in Busan.
Chris
-----Original Message-----
From: Chris Rae [mailto:Chris.Rae at microsoft.com]
Sent: 02 August 2011 14:36
To: e-SC34-WG4 at ecma-international.org
Subject: RE: Sketch of the MCE processing model (was DR 09-0315 — MCE: Preprocessing Model)
Replying to this but to WG4 instead of the smaller group, as I believe the list is working again.
Murata-san, this looks like a good approach, I think - however, I'm going to circulate it around a few people here to verify that they agree. On Step 4, am I right in understanding that you would be replacing an ignorable element with its children rather than removing it? I'm wondering what would happen in the situation of:
<element>
<ignorableElement>
<otherelement/>
</ignorableElement>
</element>
Would this turn into:
<element>
<otherelement/>
</element>
Or..
<element>
</element>
?
Chris
-----Original Message-----
From: eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] On Behalf Of MURATA Makoto
Sent: 08 July 2011 18:37
To: Chris Rae; Doug Mahugh; Alex Brown; Florian Reuter
Cc: MURATA Makoto (FAMILY Given)
Subject: Fwd: Sketch of the MCE processing model (was DR 09-0315 — MCE: Preprocessing Model)
Since the WG4 ML is not working, I am sending this sketch to you.
Regards,
Makoto
---------- Forwarded message ----------
From: MURATA Makoto <eb2m-mrt at asahi-net.or.jp>
Date: 2011/7/9
Subject: Sketch of the MCE processing model (was DR 09-0315 — MCE:
Preprocessing Model)
To: SC34 <e-SC34-WG4 at ecma-international.org>
Dear colleagues,
I have been wondering how the reference model for MCE should be specified.
I believe that real implementations will be SAX filters or wrappers of pult parsers. However, the reference processing model can be different. Its role is to clearly specify the expected output.
Conformant implementations are required to produce the same output but they do not have to follow internal details of the reference processing model.
I now think that it should be specified as a sequence of transformation steps. The input and output to each step are XML information sets.
Note: I think that MCE should not throw away PIs or comments.
Step 1: Initialization of two sets: a set (say UN) of understood namespaces and a set (say NLN) of (namespace, local name) pairs, probably from an API or MCE instruction.
Step 2: Propagating @Ignorable and @ProcessContent
If some element does not have @Ignorable, add this attribute by copying from the nearest ancestor that has this attribute.
Likewise, if some element does not have @ProcessContent, add this attribute by copying from the nearest ancestor that has this attribute.
Note: What happens when we redeclare prefixes? For example:
<one xmlns:foo="http://example.com/A" mce:Ignorable="foo">
<foo:one/>
<two xmlns:foo="http://example.com/B">
<foo:two/>
</two>
</one>
Will <foo:two/> be ignored?
Step 3: Checking non-understood and non-ignorable namespaces
Stop normal processing if, for some element E, the @Ignorable of E does not contain the namespace of E, and UN does not contain this namespace. (Hmm. Should this step follow Step 5 so that non-understood and non-ignorable elements in unselected options can be safely ignored?)
Step 4: Removing ignorable elements and attributes
An element is replaced by its contents (child elements, text chunks, comments or PIs) if
- UN does not contain the namespace of this element,
- the qualified element name of this element does not match any of the
qualified element names in the @ProcessContent of this element
Note: Is <foo:one @Ignorable="foo" @ProcessContent="foo:*"/> ignroed or retained?
Step 5: Handling AlternateContent
For each AlternateContent element, choose one of the Choice or Fallback elements. This is done by choosing the eldest Choice (if
any) such that UN contains every namespace in its @Requires or the Fallback element.
Step 6: Checking @MustUnderstand
If some of the namespaces specified by @MustUndsrand of some element is not in UN, report an error and stop normal processing.
Note: This step has to follow step5 since mustUnderstand occurring in unselected options can be safely ignored.
--
Praying for the victims of the Japan Tohoku earthquake
Makoto
--
Praying for the victims of the Japan Tohoku earthquake
Makoto
More information about the sc34wg4
mailing list