[
Lists Home |
Date Index |
Thread Index
]
- From: Rick JELLIFFE <ricko@geotempo.com>
- To: xml-dev@xml.org
- Date: Tue, 16 May 2000 00:01:21 +0800
Three points.
1) No matter whether NS identifiers are compared as strings or URIs,
I think there is an internationalization requirement that %HH be
deferenced
(if they are allowed).
2) I am not sure that the issue of relative NS identifiers can be
discussed
usefully except in the specific context of them being used to retrieve a
resource.
If the issue were merely the need to have document-local namespaces,
then
UUIDs could do the job. The thing that relative NS identifiers give, and
the reason that MS use them, surely, is because they want to locate a
schema
fragment.
It is clear that there are two very strong camps: one wants to be able
to track down a schema from the NS identifier; the other wants the NS
clear to be equally useful for any processing. At the extreme, these
views are "namespace = schema" and "namespace = string".
Ignoring the extremes as bogeymen, the two camp's views are not in
fact irreconcilable. They are the inevitable result of the
unsatisfactory
state of the XML NS REC.
I renew my suggestion that there should be some convention made
by which a namespace URI is treated as the base URI from which
W3C and other specs can place recourses using well-known relative URLs.
For example, that an XDR schema can be looked for, as the defualt
location, by appending
xdr
to the NS identifier
This simple decision would take much of the heat and conflict about
namespaces in general. It would stop opposition to relative
URLs which may be based on opposition to the identification of
NS identifier with schema URL. That would be useful, and perhaps
move this forward.
Rick Jelliffe
Academia Sinica,
Taipei, Taiwan
***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************
|