MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [emergency] Namespace
Rex Brooks wrote:
> Is there something wrong with using the OASIS urn or the actual
> specification url in the TC document repository?
To answer this question, one must, of course, refer to the
Namespace definition itself[1]. In that document, it is said:
"The [namespace] attribute's value, a URI reference, is the namespace
name identifying the namespace. The namespace name, to serve its
intended purpose, should have the characteristics of uniqueness and
persistence. It is not a goal that it be directly usable for retrieval
of a schema (if any exists). An example of a syntax that is designed
with these goals in mind is that for Uniform Resource Names [RFC2141].
However, it should be noted that ordinary URLs can be managed in such
a way as to achieve these same goals."
There are some key elements here that we need to look at
carefully:
1. It is not necessary that a namespace be "directly usable
for retrieval of a schema." Thus, Kon Wilms' objection to the fact
that there is no schema available at "www.incident.com/cap/1.0" does
*not* identify a "bug" in the CAP specification. There is nothing in
the W3's namespace recommendation that requires that the schema exist
in that location, nor that the namespace be an URL, or even that a
schema for a namespace exists *anywhere*! A namespace name is an
identifier (URI) and it is sufficient if it is nothing more than that.
It need not be an URL. Any XML processor that requires that a
namespace attribute be an URL and that the URL be the URL of a schema
is extending the definition of namespaces in a proprietary,
non-standard manner. (Note: Many namespace URI's point to
specification documents which may or may not contain schemas...)
(Having said all that, I will agree with anyone who suggests that it
is exceptionally useful when the namespace URI is, in fact, an URL and
when the URL is, in fact, the URL of the schema that defines the
namespace.)
2. The namespace "should have the characteristics of
uniqueness and persistence." This clause is the source of some concern
for the CAP specification. The problem here is that the CAP namespace
is dependent on the ability and willingness of the management of
"http://www.incident.com"; to ensure, for all time, that they do not
use the "/cap/1.0" path to identify anything else. While it may be
that the current administrators of that resource will say that it is
their intention to maintain the uniqueness of the CAP URI, it is
generally not good practice to allow the management of such a resource
to rely on such organizations. It would be much more appropriate for
the CAP namespace to be identified within a scope that has at least
the same persistence as the organization that defines CAP. Thus, a URI
from within the domain of URIs or URNs that are managed by OASIS or
some similar organization would be most appropriate.
It should also be noted that it is somewhat "unseemly" for a
standard to depend on resources maintained by organizations that have
either a commercial interest in the standard or, if non-profits, are
known to have "agendas" concerning the standard that are not
universally shared. In this case, the use of the www.incident.com
domain gives those who are associated with that domain at least the
appearance of a preferred or privileged status relative to this
standard. While I'm sure everyone will deny that such is the case, it
still must be recognized that the appearance is less than optimal.
In summary:
1. No standard is violated by the fact that the CAP schema
cannot found at the namespace URI
2. CAP should *not* rely on private domains such as
"www.incident.com".
bob wyman
[1] http://www.w3.org/TR/REC-xml-names/#ns-decl