W3C home > Mailing lists > Public > xml-names-issues@w3.org > July to September 1998


From: James Clark <jjc@jclark.com>
Date: Tue, 15 Sep 1998 14:28:10 +0700
Message-ID: <35FE170A.60C8A51C@jclark.com>
To: xml-names-issues@w3.org
It needs to reference the recently published RFC 2396, which is the
definitive generic URI syntax spec.

If we are allowing fragment identifiers in namespace identifiers (I
think we agreed this, right?), then the correct term to use per RFC 2396
is "URI reference" not URI.

The WD still fails to address the issue of relative URIs.  Are these
allowed, and if so what is the base URI to be used for resolving them?

The NSDecl production is bogus because it is is inconsisent with
allowing the xmlns attributes to be defaulted.  This was pointed out by
David Brownell; it's a serious point and in my view must be fixed before
this WD is released.

I don't think "markup vocabulary" is a term that can be used without
explanation.  The term used in other W3C specs is "vocabulary".  In any
case this should be explained, or a reference given (eg to
http://www.w3.org/TR/NOTE-webarch-extlang).  The critical point is that
this is not about reusing markup (syntax).  Lots of people have got
really confused about this, and I don't think the changes go far enough
to fix this.

In "it is better to re-use this markup rather than re-invent it", it
should say "markup vocabulary" not "markup".

I don't think the lexical equivalence definition "Note that namespace
names are URIs, the governing RFCs for which contain rules for
establishing lexical equivalence" is workable.  This is way too vague
and open-ended for interoperability.   If some implementations treat
"http://WWW.W3.ORG/" as the same as "http://www.w3.org/" and some don't,
we will not have interoperability. It's not realistic to requires
implementations of namespace processors to know about all URI schemes. 
I think lexical equivalence should just be defined as
character-for-character identity.

Received on Tuesday, 15 September 1998 03:54:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:38 UTC