Re: Questions on ZWNBS - for line initial holam plus alef

From: John Cowan (
Date: Tue Aug 12 2003 - 10:05:12 EDT

  • Next message: "RE: Assume everything on this list is ignored"

    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.



    There is / One art                      John Cowan <>
    No more / No less             
    To do / All things            
    With art- / Lessness                     -- Piet Hein

    This archive was generated by hypermail 2.1.5 : Tue Aug 12 2003 - 10:32:14 EDT