RE: [xml-dev] 14 Theses around "Namespace Documents"

["Manos Batsis" <m.batsis@bsnet.gr>]

| -----Original Message-----
| From: Tim Bray [mailto:tbray@textuality.com] 

| 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

I wish other threads could also be presented to the public in such
friendly docs. It seems as a necessary evil these days to go directly
from chaotic threads to formal blurb :-)

> 1. It is not strictly necessary for namespace
>  documents to exist

IMHO, the XML Names spec is a nice shot into a very small area. I'm sure
there are other use cases for URIs in XML (actually, we use a number of
them in various XML specs).

> 8. Content-negotiation is not a sufficiently powerful
>  tool for selecting definitive-material resources.

Does the term "definitive-material" apply? Maybe the whole idea is
something like resourceB is about resourceA, resourceC is about
resourceB so it is also relative and may be accounted for. I just saw
you have already documented the idea in section 7. (yes I'm reading the
document from bottom up ;-)

> 10. Namespace names are frequently
> not dereferenced at run-time

IMHO, this is an implementation related issue; one may build a library
to work as a cashing mechanism for example, if that is anticipated as
worthily more efficient.

> 11. Anyone should be able to write software
> to process a Web resource.

Typo? I think what you mean is "process a Web resource Description";
writing applications to handle any resource type is rather impossible.
Writing metadata about the information or pointing to them (again,
describing them as resources) is what is desired I believe?

> 13. Namespace documents should not favor the needs
> of any one application or application class.

Absolutely. This inevitably brings the need for in-document metadata
about the URIs presented. From "non-retrievable" (how's NaR -Not a
Resource- as in NaN?) to content type and more, we will have to look for
commonly needed information and standardize the way it will be expressed
to establish compatibility between implementations; otherwise this may
indeed work only for one application or application class.

> 14. Namespace documents should not be schemas
> [...] For all these reasons, the use of a schema as
>  a namespace document is not architecturally sound.

From a certain point of view, yes; but this may require more attention.
The main question IMHO is what exactly are desired semantics for
namespace documents? 

> Therefore, using a schema as a namespace document
> implies a prejudice in favor of validation-class applications.

True, but namespaces usage from my point of view is divided in three
main concepts:

a) As utilities for distinguishing between same node names (a
validational need one may say)

b) As 'resource' pointers (documents, fragments)

c) As modeling tools; It would be rather difficult to express modeling
(ie OO) in XML without having a way to point stuff (as classes).

We can go even further to a possible use for a "URI Scheme" that will
express types (document types for example). 

All the above can be extensibly applicable as semantics only when the
language is definition oriented, something that in XML lingo is
expressed as Schemata.

There is a real need for (is that the intention btw?) clean, rich
semantics for a namespace document language (how's URI Schemes
Definition Language?) and this may become the greatest thing to hit XML,
but from my point of view, use cases are mostly Schema aware/oriented.

Kindest regards,

Manos