"Dennis E. Hamilton" <> wrote on 02/21/2009
03:39:42 PM:
>
> The bigger issue seems to be the failure of ODF to profile its normative
> dependence on XML 1.0 at all. So, at the moment, all XML 1.0
edge/outlier
> cases have to be tolerated (e.g., charsets, parameters, prolog omission,
> MIME Type interaction, entity definitions, DTD occurrences, processing
> instructions, and for all I know, byte-order marks). I assume that the
> various normative statements on XML processors apply as well, though I
don't
> know about any MAYs and SHOULDs (and whose definition of such
conformance
> language is being used, in contrast to the ISO usage in those ODF
> specifications starting with IS 26300:2006).
>
No doubt XML has its quirks, but these are well known and have been around
for a decade. XML parsers handle them. In practice XML 1.0 is one of the
most widely deployed and interoperable standards in use today. No ODF
implementer sits down and writes an XML parser from scratch. They use an
off-the-shelf one, typically one that comes with their programming
environment or on their deployment platform.
So I don't see the need to profile XML. It is odd that you would see this
as a failure. Did you have a few examples in mind where this has been
done with OASIS or W3C standards, where they forbid the use of core XML
features such as processing instructions? Was this done in constrained
environments, like mobile devices, where they needed a smaller subset of
XML?
Certainly Postel's robustness principle is good advice for implementors: "
Be conservative in what you do; be liberal in what you accept from
others.". Conservative output should shun the edge features of XML and
stick to the core. But an ODF processor should be prepared to handle
anything that a conformant XML document can throw at them. In fact, any
reasonable ODF processor should be robust enough to handle non conformant
ODF documents as well, including potentially invalid instances. This is
more reasonable than failing or giving a user a cryptic error message.
-Rob
