From: John Cowan (jcowan@reutershealth.com)
Date: Tue Aug 12 2003 - 10:05:12 EDT
Philippe Verdy scripsit:
> Of course one is not required to build an actual DOM tree, however XML, HTML
> and alike is now defined in terms of the DOM, where the text/xml syntax is
> just a serialization,
This is absolutely false. XML is defined by the XML Recommendation, which
is entirely syntactic. As a matter of convenience, many other XML
recommendations use the XML Infoset, which is by no means the same as the
DOM. The DOM is an abstract API for programmatic access to the content
of XML documents.
> which is the only place where whitespaces
> normalization is defined (such normalization does not occur at the DOM
> level, and a XML document may be serialized with another concrete syntax
> than the one assigned to the "text/xml" MIME type, registered and documented
> by the W3C.
"May" be, yes. You can serialize it in ASN.1 if you want to. That doesn't
make ASN.1 an instance of XML.
> [W]hitespace normalization in XML documents
> serialized as "text/xml" is mandatory, or it is not a valid "text/xml"
> serialization.
Very true. But what is this whitespace normalization?
1) Throughout the document, line-end characters and sequences are normalized
to LF. Not relevant here.
2) In attribute values, LF, CR, and TAB characters are normalized to spaces.
Not relevant here.
3) In attribute values that have a declared type other than CDATA, multiple
spaces are compressed to a single space, and leading and trailing spaces
are removed. After this is done, there can be no spaces in attributes
of type ID, IDREF, ENTITY, NMTOKEN, NOTATION, or enumerated types.
In the types IDREFS and ENTITIES, spaces are used to separate
individual tokens, none of which may begin with a combining character.
In the remaining type, NMTOKENS, individual characters may begin
with a combining character, so it is possible that such a token, if
not the first in the attribute, will be rendered in a peculiar way,
with the combining character placed over the separating space.
But that is a mere rendering glitch and in no way affects anything.
> No XML application is required to use the "text/xml"
> MIME syntax, and there exists such examples (for example the serialization
> and compression formats used by WAP, MMS, Nec's i-Mode, and SOAP).
That is not the definition of "XML application" given in the XML Recommendation,
which is the sole authority on the subject. You can invent your own
definitions if you like, but you need not expect to be listened to.
> If an application does not build the DOM tree, it is still required to
> perform namespace resolution
No XML application is required to perform "namespace resolution", whatever
that may be.
> to solve named entities according to the
> standard "text/xml" MIME rules formulated by the W3C reference,
Only certain named entities *must* be resolved: specifically, internal
entities that are defined in the internal subset.
> In my opinion, all XML-based languages should
> be defined now in terms of its DOM structure, and the XML application should
> be defined by a valid DTD, or beter now with a now standard XSD schema, that
> can be processed by validating parsers (parsers that absolutely need to
> create a DOM-like tree or flow of tokens with strictly defined properties,
> value sets and behavior.)
In your *opinion*.
> Without DOM interoperability, XML would be another imprecise language like
> HTML, with very little reusability due to naming conflicts.
Nonsense.
*plonk*
-- There is / One art John Cowan <jcowan@reutershealth.com> No more / No less http://www.reutershealth.com To do / All things http://www.ccil.org/~cowan With art- / Lessness -- Piet Hein
This archive was generated by hypermail 2.1.5 : Tue Aug 12 2003 - 10:32:14 EDT