Is this an MCE syntax error?

[Francis Cave]

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