MCE questions
Thorsten Behrens
tbehrens at novell.com
Fri Aug 19 23:54:26 CEST 2011
Hi Murata-san,
below some input on how LibreOffice does things currently, and some
thoughts -
MURATA Makoto wrote:
> Q1. Suppose that an element is ignored. Is anything in this element
> allowed by MCE? In particular, are (1), (2), and (3) (shown below)
> allowed?
>
> (1) @mustUnderstand specifying a non-understsood namespace
> (2) non-understood and non-ignorable elements/attributes
> (3) Incorrect use of MCE elements and attributes
>
> For example:
>
> <U:foo xmlns:mce="http://schemas.openxmlformats.org/markup-compatibility/2006"
> xmlns:U="http://understood.com/"
> xmlns:NU1="http://non-understood.com/one"
> xmlns:NU2="http://non-understood.com/two"
> mce:ignorable="NU1">
> <NU1:bar mce:mustUnderstand="NU2"/> <!-- Example of (1) -->
> <NU1:bar>
> <NU2:hoge/> <!-- Example of (2) -->
> </NU1:bar>
> <NU1:bar mce:Ignorable="1"/> <!-- Example of (3) -->
> </U:foo>
>
Currently LibreOffice rather implicitely supports ignorable
namespaces, so all three examples would be skipped. In this case, I
also believe it follows the principle of least surprise, and I don't
think, that in general nested elements of ignored content should be
interpreted.
> Q2: Also suppose that a Choice or Fallback is not chosen by the MCE
> processor. Is anything in this element allowed by MCE? In
> particular, are (1), (2), and (3) (shown in Q1) allowed?
>
> For example:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <U1:foo xmlns:mce="http://schemas.openxmlformats.org/markup-compatibility/2006"
> xmlns:U1="http://understood.com/one"
> xmlns:U2="http://understood.com/two"
> xmlns:NU1="http://non-understood.com/one"
> xmlns:NU2="http://non-understood.com/two"
> mce:ignorable="NU1">
> <mce:AlternateContent>
> <mce:Choice Requires="U2">
> <U2:bar/>
> </mce:Choice>
> <mce:Fallback>
> <U1:hoge1 mce:mustUnderstand="NU2"> <!-- Example of (1) -->
> <NU2:hoge/> <!-- Example of (2) -->
> <U1:hoge2 mce:Ignorable="1"/> <!-- Example of (3) -->
> </U1:hoge1>
> </mce:Fallback>
> </mce:AlternateContent>
> </U1:foo>
>
LibreOffice currently ignores mustUnderstand, so example (1) would
pass (and ignored), example (2) would be skipped, and the attribute
in example (3) would be ignored, too (though trigger some diagnostic
shell output). As a naive reader of the standard, though, I'd expect
(1) and (2) to be interpreted. No strong opinion on (3).
> Q3: Is anything in an application-defined extension element allowed by
> the MCE preprocessor? In particular, is syntactically-incorrect use
> of MCE elements and attributes allowed?
>
> <extLst xmlns:mce="http://schemas.openxmlformats.org/markup-compatibility/2006">
> <ext uri='http://purl.oclc.org/ooxml/spreadsheetml/versionTwoExtension'>
> <v2:newContent
> xmln:v2='http://purl.oclc.org/ooxml/spreadsheetml/versionTwoExtension'
> mce:mustUnderstand="1"> <!-- Example of incorrect @mustUnderstand-->
> <mce:Choice Requires="3"> <!-- Example of incorrect Choice-->
> <mce:Fallback> <!-- Example of incorrect Fallback-->
> <mce:AlternateContent/> <!-- Example of incorrect AlternateContent -->
> </mce:Fallback>
> </mce:Choice>
> </v2:newContent>
> </ext>
> <ext uri='http://www.extension.com/versionOneExtension'>
> <v2:moreContent xmlsn:v2='http://www.extension.com/versionOneExtension'>
> …
> </v2:moreContent>
> </ext>
> </extLst>
>
LibreOffice would currently trip over the above content, and I
believe it should be considered invalid. Not doing so possibly
imposes a certain nesting order of how to handle extension lists and
mce, that would unnecessarily restrict implementer's freedom - or is
there anything to be gained by permitting this?
Cheers,
--
Thorsten Behrens
Novell GmbH, Nördlicher Zubringer 9-11, 40470 Düsseldorf; GF: Jeff
Hawn, Jennifer Guild, Felix Imendörffer; HRB 21108 (AG Düsseldorf)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20110819/8389236e/attachment.pgp>
More information about the sc34wg4
mailing list