[
Lists Home |
Date Index |
Thread Index
]
Tim Bray wrote:
> Subject : [xml-dev] 14 Theses around "Namespace Documents"
>
> I have just posted some arguments about namespaces and
> namespace documents as a contribution to TAG debate - I
> suspect many here will be interested. See
>
> http://lists.w3.org/Archives/Public/www-tag/2002Feb/0093.html
>
> -Tim
Thanx, Tim. Interesting material to build upon. Now, w/ my comments :
(Issue 1)
"It is not strictly necessary for namespace documents to exist."
Sorry, this is one I can't agree with 100%. Well, at least, I mean it
deserves more debate about this, when you say :
"[...]there are many widely-deployed namespaces (e.g. for Microsoft Office)
whose namespace names are URNs and for which there exists no namespace
document; these namespaces nonetheless effectively serve the purpose of
enabling software to recognize markup and to avoid name collisions. This is
an existence proof that the existence of namespace documents is not strictly
necessary".
At first glance, this *effectively is* a fact. But this is kinda
*MS-specific* (or whatever corporation) historical fact, as a software
development company which builds (their) software using (W3C) standards
(which we are all concerned about, eventually) the way they want (freedom).
Then, this doesn't mean it's *the only* proper, reasonable approach of using
[xml-names] functionality, just because the latter has omitted to give more
hints about "how to give an XML namespace a document representation".
(so came your RDDL which I find quite fine, for a starter on the issue)
So my opinion is, I guess, it would be wiser perharps to put "officially"
(in an [xml-names] 2nd edition and/or subject-related IETF RFCs ?) more
restrictions about it. Well, I am thinking of sth like a
mechanism -hopefully defined after URI clarifications- which would, right
from the start -i.e, the parsing of an occurrence of a namespace URI string-
and both for human beings AND machines, say : "this namespace URI *does*
(*or not*) have an associated namespace document" (then, more
rules/conventions per URI schemes follow to provide a standard process in
order to infer about the latter's URI [*])
So I am talking about kind of "self-describing URIs" when they are serving
the purpose of namespace identification and whether there exists an
*explicitly* coupled (or not) namespace document.
Does it make sense?
[*] as a test of concept :
http://www.rddl.org/ == YES, this IS the namespace URI of RDDL AND the URI
of RDDL spec. document
http://rddl2:specification@rddl.org/ == YES, this IS the ns URI of RDDL v2
but NO, this is NOT the URI of RDDL v2 spec. document (given that, the usage
of <userinfo> provided in this example is purely conventional for this
purpose of explicitation -here, meaning "this is NOT the ns document, just
the ns URI"- see [rfc2396])
( So that people/apps wishing to get to the RDDL2 ns document would just
enter, instead, sth like : http://www.rddl.org/rddl2 )
Yes, I know : my idea, in this form is weak regarding some security issues
like the "URL semantics attack" [url-sem-attack] - so it needs more
discussion about formalizing it - if found useful.
E.g, explicitation to be done "later" in the URI, maybe in the [rfc2396]'s
<path> generic syntax construct? Or <query> part maybe?
Anyway, I guess, the solving of the issue this way would probably pertains
to the specification level of IETF RFCs, rather than solely W3C's.
Issues 2 to 14 : I'm OK w/ them all (AFAIK)
[xml-names]
http://www.w3.org/TR/REC-xml-names
[rfc2396] <userinfo> in section : "3.2.2. Server-based Naming Authority"
http://www.ietf.org/rfc/rfc2396.txt
[url-sem-attack]
http://www.counterpane.com/crypto-gram-0102.html#7
Rgds,
--CJ
|
