OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Resource Gloss (Human Readable)

At 12:25 PM 1/5/01 -0500, John Cowan wrote:
>Charles Reitzel wrote:
> > My basic point would be that your job probably isn't done until you
> > do handle NS entities.  OTOH, RDDL probably isn't done until it can
> >  map PUBLIC IDs to SYSTEM IDs like XML Catalog (as others have
> > suggested in this thread).  Two 3/4 overlapping specs would be,
> > well, redundant.
>OTOH it might be that the job of saying "What are the associated
>[entities] for this namespace?" and "What is the local meaning of this
>system id or public id?" are actually quite orthogonal, and should
>be handled by separate mechanisms.

Partly disagree.  For DTDs, XSchema docs, RDF docs, etc., the "local
meaning" question is often directly related to the namespace.

From the implementation and, more important, deployment points of view, the
two are intertwined.  Implementors will have to keep these lookup tables
around and software will have to support them.  Why have two flavors for
only slightly different types of entity references?  I blame the NS Spec for
not making them completely consistent.  

> > As an aside, I think the difference between PUBLIC IDs and NS URIs
> > is not important.  I checked the grammar for the NS "URI" and it is
> > a garden variety XML attribute value, not even a URI, URN, let
> > alone a URL.
>In order to be xml-names correct, it has to be syntactically a URI;

Does it?  The NS spec reads:

Attribute Names for Namespace Declaration 
[1]  NSAttName ::=  PrefixedAttName | DefaultAttName


[Definition:] The 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. 
</Quote> [1]

Now, depending of which phrase you think is most normative, this has three
conflicting interpretations of what the RHS of a NS declaration contains: 

1) from "the attribute's value"

  => It is *just* a vanilla XML attribute value.

2) from "a URI reference"

  => It is required to use URI syntax (rfc 2396).

3) from "is the namespace name ... uniqueness and persistence".

  => It is required to use URN syntax (rfc 2141).

The defacto interpretation, is either 1) or 2), I'm not sure which.  

3) requires a "urn:" prefix, which is only rarely seen and is required by no
NS aware software that I can think of.  [2]

2) seems to impose the "<scheme>://<authority><path>?<query>" structure [3],
which is at odds with the "-//Joe-Bob Briggs//Bad Movies//Favorites" type of
identifier. Is this ISO?  As an aside, IE5 requires this format for the
PUBLIC part of the DOCTYPE statement.  Again, there is the question of
software support.

I am forced to conclude that, in practice, only 1) can be relied upon.

> > I look at the production for PublicId (in XML, not
> > XML Catalog) and I see it has character set limitations (roughly
> > a-z,A-Z + comic book cursing).

From [4]

PubidChar ::= #x20 | #xD | #xA | [a-zA-Z0-9] | [-'()+,./:=?;!*#@$_%]

> > To my mind, the discussion is all about a) deciding if a NS "URI" is
> >  an entity or not and b), if it is, what kind.  Personally, I think
> >  b) is a minor point until you decide a).
>A URI labels a resource, which may have (MIME) entity bodies associated
>with it.  A URI can't *be* an entity.

Exuse me. Allow me to rephrase:

To my mind, the discussion is all about a) deciding if a NS "URI" refers to
an entity or not and b) if it does, what kind.  Personally, I think b) is a
minor point until you decide a).

take it easy,
Charles Reitzel

[1] http://www.w3.org/TR/1999/REC-xml-names-19990114/#ns-decl
[2] http://www.ietf.org/rfc/rfc2141.txt
[3] http://www.ietf.org/rfc/rfc2396.txt
[4] http://www.w3.org/TR/2000/REC-xml-20001006#NT-PubidLiteral