Another look at namespaces

[Don Park]

Paul,

>If we develop this mechanism now then the first wave of XHTML software
>will be automatically ready for XHTML 2.0 (not to mention
>e-commerce). I
>can understand the wish to delay the problem but it just means that we
>cause a train wreck later on. I am deathly afraid, however, that if we
>set a precedent of pretending that these three variants are "one
>language" we will continue down that path as we develop more and more
>incompatible new versions.

I respect your wisdom, but:

I feel that planning too far out is just as dangerous as being too
short-sighted.  Can you provide us with some examples of the kind of
problems that might necessitate incompatible changes to XHTML?  Why penalize
the masses with the some unforseeable need?

I also feel that if future versions of XHTML are incompatible with XHTML 1.0
then they should not be called XHTML in the first place.  Why confuse the
masses by treating incompatible standards as one?

Best,

Don Park    -   mailto:donpark at docuverse.com
Docuverse   -   http://www.docuverse.com


>-----Original Message-----
>From: owner-xml-dev at ic.ac.uk [mailto:owner-xml-dev at ic.ac.uk]On
>Behalf Of
>Paul Prescod
>Sent: Monday, August 30, 1999 5:30 AM
>To: xml-dev
>Subject: Another look at namespaces
>
>
>There are two separate issues here.
>
>#1. In 1999 XHTML can either have three namespaces or one. If it has
>three then there will be a one-to-one relationship between namespaces
>and grammars so that a programmer can know the grammar of the input
>data. Programmers that want to treat the three as one will
>have to do so
>by issuing some command to their namespace processor or (better) by
>usuing a namespace processor that recognizes an embedded instruction.
>
>Either way works because programmers know today what to expect and can
>write their code accordingly. Hell, we could have one namespace per
>element type or one namespace for all W3C specifications and you could
>still write code that works.
>
>I think that people are really concerned more about the precedent than
>today's issue.
>
>#2. In 2000, 2001, 2002, etc. there will be new versions of XHTML. Some
>(probably all) of these will be backwards incompatible as every version
>of HTML has been backwards incompatible: a document conforming to the
>new vocabular/grammar can break code expecting the old
>vocabulary/grammar.
>
>It is *vital* that a) there be a way to announce this
>backwards-incompatibility and b) there be an infrastructure that allows
>a mapping from new to old. The namespace is the obvious way to do the
>former. We have no good mechanism for the latter.
>
>As I've said, this is also necessary for e-commerce and every other XML
>application.
>
>
> Paul Prescod
>
>xml-dev: A list for W3C XML Developers. To post,
mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN
981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following
message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)