Re: Sketch of the MCE processing model (was DR 09-0315 — MCE: Preprocessing Model)
MURATA Makoto
eb2m-mrt at asahi-net.or.jp
Fri Sep 23 10:51:44 CEST 2011
Chris,
> 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.
Yes, that is my intention.
> 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.
It appears that my model is not good enough, but let us think how
it works.
Step 2 does not change anything, since both elements have @Ignorable.
Step 3 will not stop normal processing, since the namespace
for the first element is ignorable and that for the second
element is also ignorable.
Step 4
First, I am afraid that my itemized list for Step 4 lacks the
third bullet, namely
- the namespace of this element is not understood
Assuming this bullet is incorporated, Step4 provides
different results depending on which namespace is
understood.
Case 1: neither of the namespaces for the prefixes "yes"
and "no" are understood
Step 4 first replaces the first element by its content,
namely <yes:a Ignorable="yes" /> preceded and followed
by whitespace. Then, Step 4 replaces this element by an
empty sequence. Thus, we get a sequence of whitespace
text chunks.
Case 2: the namespace for "yes" is not understood while
that for "no" is understood
As in Case 1, Step 4 first replaces the first element by its
content, namely <yes:a Ignorable="yes" /> preceded and
followed by whitespace. But Step 4 does not touch the
second element, since the prefix is understood.
It appears that this is different from what was intended
by the MCE inventor.
Case 3: the namespace for "yes" is understood while
that for "no" is not understood
Step 4 does not touch the first element. But Step 4
replaces the second element by an empty sequence.
Thus, we get
<no:a Ignorable="no">
</no:a>
Case 4: both of the namespaces for "yes" and "no" are understood
Step 4 does not touch the first element. It does not touch the second
element either. Thus, we get
<no:a Ignorable="no">
<yes:a Ignorable="yes" />
</no:a>
> Re. Step 3: What is meant by "stop normal processing"? Is it the same as ignoring an element?
No, the program crashes. What should happen when elements in
non-understood and non-ignorable namespaces are encountered?
I have another question. Consider the following document. The
only difference from your original example is that @Ignorable for
the second element is removed.
<no:a Ignorable="no">
<yes:a/>
</no:a>
When neither "yes" and "no" are understood, what will happen? Should
the MCE processor crash when it encounters the second element? Or,
it should not since it is already in the ignoring mode when it encounters
the second 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.
Actually, Step 4 is intended to be recursively applied in the top-down
manner. The second condition is intended to stop this recursive
application. Thus, I don't think that the second condition
is the reverse.
>
> 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.
Hmm. What I did is consistent with the following description
in Page 22.
> A markup consumer shall not generate an error based on any
> MustUnderstand attribute applied to an element contained within
> the content of the unselected Choice or Fallback element. A
> markup consumer shall not generate an error based on any
> markup that is contained within an unselected Choice or
> Fallback element, even if that markup is not conformant to
> this Part of ISO/IEC 29500.
But what you wrote appears to be consistent with another
description in the same page.
> In processing an AlternateContent element, the
> attributes of every child Choice or Fallback
> element shall be processed and checked for
> conformance to this Part of ISO/IEC 29500,
> regardless of whether the Choice or Fallback
> element precedes or follows the selected
> alternative in markup order. [Note: Checking the
> conformance of attributes of all Choice and
> Fallback elements, including those that follow the
> selected alternative, ensures that conformance
> violations detected by older markup consumers are
> detected by newer markup consumers that understand
> additional newer namespaces. end note] If the
> AlternateContent element’s child Choice or
> Fallback elements include an attribute from a
> namespace that is not understood and is not
> ignorable, the markup consumer shall generate an
> error. Likewise, a markup consumer shall generate
> an error if it encounters a MustUnderstand
> attribute included on a Choice or Fallback element
> that identifies a namespace that it does not
> understand.
Help!
> 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?
The NVDL script shown in A.1 is intended to capture syntactical restrictions
on the various MCE constructs.
>
> Let's discuss further in Busan.
It appears that we really do not understand Part 3. Perhaps, we should try
to read a few pages together.
Regards,
Makoto
> 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
>
>
>
--
Praying for the victims of the Japan Tohoku earthquake
Makoto
More information about the sc34wg4
mailing list