Sketch of the MCE processing model (was DR 09-0315 ? MCE: Preprocessing Model)

[MURATA Makoto (FAMILY Given)]

Step 4 is intended to replace ignorable elements by their contents (i.e., a sequence 
of text chunk and child elements), but it should be applied recursively.  This recursive 
step can remove the entire subtree or it can stop when processContents
is in the way.

Regards,
Makoto

> 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

Cheers,
Makoto