Is this an MCE syntax error?

Francis Cave francis at franciscave.com
Thu Sep 27 12:31:43 CEST 2012


If the intent was to allow for future extension of MCE, in the current
version of MCE any <foo:bar/> in an ACB must EITHER be in a non-understood
namespace OR defined in the configuration of the MCE processor. So that adds
another category of things that can be contained in a configuration: a
special category of application-defined extension elements that can occur
directly within <mce:AlternateContent>.

Francis



> -----Original Message-----
> From: John Haug [mailto:johnhaug at exchange.microsoft.com]
> Sent: 26 September 2012 22:08
> To: 'SC34'
> Subject: RE: Is this an MCE syntax error?
> 
> That's a valid assessment, Francis.  I was speculating.  When I do
> that, I usually end up eating crow. :)
> 
> While I'm waiting for info from the authors in Windows, our Office
> developer noted he thinks the intent of the wording was to disallow my
> example while allowing a "v2" of MCE to extend AlternateContent.  The
> idea being that a MCE v2 specification would be backward compatible and
> its namespace ignorable to allow parsing by a MCE v1 preprocessor.  I
> think that's a very valid scenario and the text could more clearly
> indicate this intent.  I'm hoping to hear back soon from my contact
> over in Windows who was more familiar with the original OPC/MCE design
> to verify this is indeed what was intended.
> 
> John
> 
> -----Original Message-----
> From: Francis Cave [mailto:francis at franciscave.com]
> Sent: Tuesday, September 25, 2012 4:49 PM
> To: 'SC34'
> Subject: RE: Is this an MCE syntax error?
> 
> John
> 
> While your example may be conceptually valid, it doesn't immediately
> strike me as particularly logical or clear. It seems to me that you are
> describing two choices, one in which <v1:bar> follows <v2:foo> and the
> other in which <v1:bar> precedes <v1:foo>. I would therefore expect
> this to be expressed as
> follows:
> 
> <mce:AlterateContent>
>   <mce:Choice>
>     <v2:foo> ... </v2:foo>
>     <v1:bar> ... </v1:bar>
>   </mce:Choice>
>   <mce:Fallback>
>     <v1:bar> ... </v1:bar>
>     <v1:foo> ... </v1:foo>
>   </mce:Fallback>
> </mce:AlterateContent>
> 
> What you have proposed could, I suppose, be interpreted as a short-hand
> for the above (what old SGML hands like me will recognize as akin to
> markup minimization), but it really doesn't strike me as very useful,
> since the standard syntax is so much more flexible, allowing for a
> whole host of different alternatives, e.g.
> 
> <mce:AlterateContent>
>   <mce:Choice>
>     <v2:foo> ... </v2:foo>
>     <v1:bar> ... </v1:bar>
>   </mce:Choice>
>   <mce:Choice>
>     <v3:foo><v1:bar> ... </v1:bar> ... </v3:foo>
>   </mce:Choice>
>   <mce:Choice>
>     <v1:bar><v4:foo> ... </v4:foo> ... </v1:bar>
>   </mce:Choice>
>   <mce:Fallback>
>     <v1:bar> ... </v1:bar>
>     <v1:foo> ... </v1:foo>
>   </mce:Fallback>
> </mce:AlterateContent>
> 
> To my mind the elements <mce:choice> and <mce:fallback> should be
> sufficient to define any imaginable ACB. If you are suggesting that,
> for specific applications of MCE, it must be possible to use short-hand
> forms to express what would otherwise be quite lengthy ACBs, we have to
> make it clear that Part 3 specifies only core features of ACBs and
> other features are defined by the application.
> 
> I think we also have to specify the limits on what additional MCE
> features can be added by an application. Otherwise the value of Part 3
> is significantly diminished. We already have application-defined
> extension elements that cause MCE processing to be suspended. Florian's
> blog suggests that there is possibly another class of elements that
> could cause MCE processing to be resumed inside elements that cause MCE
> processing to be suspended. Now we have short-hands for complex ACB
> choices. Where does this end?
> 
> Regards,
> 
> Francis
> 
> 
> > -----Original Message-----
> > From: John Haug [mailto:johnhaug at exchange.microsoft.com]
> > Sent: 25 September 2012 23:37
> > To: francis at franciscave.com; 'SC34'
> > Subject: RE: Is this an MCE syntax error?
> >
> > One potential case that comes to mind (purely speculative on my part
> -
> > I'm not speaking about any particular Microsoft product!) is that the
> > non-MCE markup inside an ACB wrapper should simply appear in place in
> > the post-processed markup.
> >
> > I *think* this is a conceptually valid scenario...  Say I have a
> > markup specification that has had changes from one version to
> another.
> > In v1, the foo element comes after the bar element.  In v2, the foo
> > element comes before the bar element.
> >
> > <mce:AlterateContent>
> >   <mce:Choice>
> >     <v2:foo> ... </v1:foo>
> >   </mce:Choice>
> >   <v1:bar> ... </v1:bar>
> >   <mce:Fallback>
> >     <v1:foo> ... </v1:foo>
> >   </mce:Fallback>
> > </mce:AlterateContent>
> >
> > I can check with the folks who designed this to see what scenario
> they
> > had in mind for the text Murata-san quoted below.
> >
> > I'm not sure whether tightening MCE to now disallow non-mce elements
> > as children of AlternateContent will break anything.  Certainly, it's
> > theoretically possible.  As with other cases where we've wanted to
> > tighten the spec, perhaps the right (safest) thing to do is recommend
> > against it as "deprecated" behavior without making it syntactically
> > invalid.
> >
> > John
> >
> > -----Original Message-----
> > From: Francis Cave [mailto:francis at franciscave.com]
> > Sent: Saturday, September 22, 2012 11:17 AM
> > To: 'SC34'
> > Subject: RE: Is this an MCE syntax error?
> >
> > Murata-san
> >
> > Thank you for your further explanation. I now agree with you. If the
> > MCE processor only understands the MCE namespace, and in addition to
> > that only knows whether another namespace is understood or not (i.e.
> > is in the configuration or not), the four cases that you mention are
> > the only possible interpretations. The standard does not specify what
> > an MCE processor should do with the element <foo:bar/> in your
> > example, if it is understood, so its behaviour is unspecified.
> >
> > I think we have to hope that we can prohibit <foo:bar/> in this
> > position within an ACB. It does not make any sense for only non-
> > understood elements to be allowed in this position. That would not
> > serve any useful purpose.
> >
> > Francis
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] On Behalf Of
> > MURATA
> > > Makoto
> > > Sent: 22 September 2012 09:28
> > > To: SC34
> > > Subject: Re: Is this an MCE syntax error?
> > >
> > > 2012/9/21 Francis Cave <francis at franciscave.com>:
> > > > Presumably, if the MCE processor understands namespace 'foo', it
> > > > will
> > > know
> > >
> > > Actually, the MCE processor understands the MCE namespace only.
> > > But it will behave as instructed by a given configuration, which is
> > > a set of namespaces understood by the application program.
> > >
> > > Do you mean that the foo namespace is included in the given
> > > configuration?  (In other words, the application program understand
> > > it.)
> > >
> > > > what to do with your example, which will presumably be to replace
> > > > the
> > > entire
> > > > ACB with something else that is syntactically correct.
> > >
> > > But such a behavior is never specified.
> > >
> > > If the ns for foo is included in the given configuration, what
> > > should happen?
> > > Is this an error?  My understanding of the spec is as follows:
> > >
> > > Case 1: understood and ignorable
> > >             I have no ideas.
> > > Case 2: understood and  non-ignorable
> > >             I have no ideas.
> > > Case 3: not understood and ignorable
> > >              not an error
> > > Case 4: not understood and non-ignorable
> > >              error
> > >
> > > I think that this should be an error for all these cases.
> > >
> > > Regards,
> > > Makoto
> > >
> > >
> > > > But what that might
> > > > be is completely unknowable, because <foo:bar/> might say
> > > > something
> > > like: if
> > > > you understand 'foo', change the choices and the fallback in some
> > > specified
> > > > way.
> > > >
> > > > In effect, the namespace 'foo' would contain extensions to the
> MCE
> > > namespace
> > > > itself.
> > > >
> > > > Francis
> > > >
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] On Behalf Of
> > > MURATA
> > > >> Makoto
> > > >> Sent: 20 September 2012 16:29
> > > >> To: SC34
> > > >> Subject: Is this an MCE syntax error?
> > > >>
> > > >> Dear colleagues,
> > > >>
> > > >> Consider
> > > >>
> > > >> <mce:AlternateContent>
> > > >>   <foo:bar/>
> > > >>   <mce:Choice ...>..</mce:Choice   ... >
> > > >> </mce:AtternateContent>
> > > >>
> > > >> where mce and foo are prefixes for the MCE namespace and an
> > > ignorable
> > > >> namespace.Does this fragment have an error?
> > > >>
> > > >> Suppose that an application program understands the namespace
> foo.
> > > >> Then, this document has an MCE syntax error. Suppose that it
> does
> > > not.
> > > >> Then, there are no MCE errors.
> > > >>
> > > >> This is because of the following text in 10.2.1 of Part 3.
> > > >>
> > > >> AlternateContent elements might have ignored attributes or
> > > >> contain ignored child elements. Markup consumers shall not
> > > >> generate an error when encountering such attributes or child
> elements.
> > However,
> > > >> markup consumers shall generate an error when encountering an
> > > >> attribute or child element of the AlternateContent element that
> > > >> belongs to a namespace that is neither understood nor ignorable.
> > > >> [Note:  In
> > > addition
> > > >> to Choice and Fallback elements, an ignored element can occur as
> > > >> a child of AlternateContent. end note]
> > > >>
> > > >> I hate this design.  Syntactical correctness of data shouldn't
> > > depend
> > > >> on application programs.
> > > >>
> > > >>
> > > >> Regards,
> > > >> Makoto
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > Praying for the victims of the Japan Tohoku earthquake
> > >
> > > Makoto
> 




More information about the sc34wg4 mailing list