RE: [emergency] Namespace

["Bob Wyman" <bob@wyman.us>]

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



-----Original Message-----
From: Rex Brooks [mailto:rexb@starbourne.com] 
Sent: Wednesday, March 31, 2004 9:45 AM
To: R. Allen Wyke; Art Botterell
Cc: Kon Wilms; Emergency TC; Gary Ham
Subject: Re: [emergency] Namespace


Is there something wrong with using the OASIS urn or the actual
specification url in the TC document repository?


Since this actually raises some TC Process questions I had assumed
were resolved, I have started a discussion on the chairs list for
several related issues that apply to all TCs, and that have apparently
not been resolved.


While my questions may raise a temporary flamestorm, I think that,
with ISO adopting the first batch ebXML specs, and with CAP passing
(barring a last minute barrage of no votes), the convergence of
standards will eventually iron out the wrinkles we all continue to
wrestle with.


A standard XML Schema Validation Service would be a fine help to
start, but it would have to be verified as validating standards that
demonstrably work successfully with the major web stacks, but most
especially with the stacks that represent the vast majority of market
share on the web, Apache with ~62-67% and Microsoft ~22-27%:


http://news.netcraft.com/archives/web_server_survey.html


Ciao,
Rex






At 9:48 PM -0500 3/30/04, R. Allen Wyke wrote:
On Mar 30, 2004, at 7:08 PM, Kon Wilms wrote:

(Note www.incident.com/cap/1.0 is missing from the namespace since
there
isn't actually anything at that location that we could determine)..
?--

Art, are you planning on hosting the schema to be used for validation?

--
R. Allen Wyke
Chair, OASIS Emergency Management TC
emergency-tc@earthlink.net


To unsubscribe from this mailing list (and be removed from the roster
of the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_w
orkgroup.php.




-- 

Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request