Is this an MCE syntax error?

[John Haug]

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