Cart
[Home] [By Thread] [By Date] [Recent Entries]
Tim Bray wrote: > Subject : 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@r.../ == 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
|
