Re: ERB decisions on A.17, B.9, and other questions
I'mna afraid most of my reactions to the following are rather flamish.
Apologies, but no regrets for that fact.
At 12:33 PM 10/19/96, Michael Sperberg-McQueen wrote:
>The ERB agreed on the following position statements:
> * We will maintain a list of topics to be addressed in
> future revisions of XML.
> * We will include some version of this list in the specification
>In the light of these agreements, the ERB reconfirmed its earlier
>decision that XML 1.0 will not have SDATA entities. It is thought that
>most uses of SDATA entities are adequately served by character
>references to Unicode characters (see example below). Techniques for
>dealing with non-Unicode characters, specification of glyphs rather than
>characters, and related topics (such as possible mechanisms for document
>private agreements governing the ISO 10646 Private Use Areas) will be
>addressed in future revisions.
>Instead of a declaration like
> <!ENTITY auml SDATA "[auml ]">
How do I declare a character like "TENGWAR VOWEL LETTER A" or "ME GLYPH
GARDINER 201" (Middle Egyptain). It's just 宊 or something.
My gut reaction to that is #$*#&$#?!
>any XML processor can work properly with a declaration of the form
> <!ENTITY auml "ä"> <!-- auml = a umlaut, U+00E4 -->
These declarations must be included automatically, if we hope to have
anyone _use_ XML. (Which does not seem to be a major concern, as far as I
>On question B.9, the ERB decided:
> * In version 1.0, XML will not have public identifiers, only
> system identifiers.
> * In version 1.0, system identifiers will be URLs.
> * In version 1.0, URLs need not carry the FSI-style <url> label.
>Whether system identifiers in XML 1.0 will be *allowed* to carry the
><url> label remains an open question.
>Addition of public identifiers and extension of system identifiers
>to other formats will be taken up in preparation of future versions
>The rationale for these decisions was that URLs are well understood
>and well established, and can handle both remote and local addresses.
>Restricting external identifiers to URLs helps keep the specification
>simple. In the long run, however, public identifiers are desired by
>many users and may provide solutions to the well known fragility
>problems associated with URLs. Better infrastructure, in the form
>of catalog management tools and http-based catalog resolution
>services, would help make the introduction of public identifiers into
We should specify and reserve the syntax for Public Identifiers now. It's
not like we don't know what they will be.
We should certainly _accept_ the <url> prefix, so that those of us who are
interested in doing things right will be able to. Come on, test URN
deployments are already taking place -- must we repeat the mistakes of the
past HTML's location-only syntax has already set the world back 10 years by
spreading a bad model into millions of minds, just as SGML has failed to
move the world forward 20 years, by cloaking good ideas in crappy syntax.
I'd like that the end of this process will be something that can be
endorsed instead of inveighed against. I'm starting to worry.
David Durand firstname.lastname@example.org \ david@dynamicDiagrams.com
Boston University Computer Science \ Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams
MAPA: mapping for the WWW \__________________________