ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> xml-dev
xml-dev
Re: [xml-dev] Re: [dsdl-comment] Re: [xml-dev] Re: Re: [xml-dev] DSDL: use cases: namespace declaration notation
by Tim Bray other posts by this author
Jun 14 2002 5:56PM messages near this date
Re: [xml-dev] Re: [dsdl-comment] Re: [xml-dev] DSDL: use cases: namespace declaration notation | Re: [xml-dev] DSDL: use cases: namespace declaration notation
james anderson wrote:

>  I do not argue with the spec. I note that the recommendation specifies a notion which is u
ntenable. In order to implement the
>  specification one must supplant or contradict its notion in some significant manner.

This line of argument is vacuous and I've managed to avoid getting 
irritated by it for some 25 posts now but patience ran out.  The 
namespaces rec defines a condition it calls "being in a namespace" and 
provides syntactic rules whereby element types and atribute names may be 
said "to be in a namespace".  It notes explicitly that the namespaces 
defined in this document differ from the conventional (computer-science) 
set-theory-based usage.

Similarly, the XML recommendation defines the term "type" and uses it in 
a sense that differs quite strongly from the "type" of variables in C 
programs, or the lead objects that used to be used in printing.  HTML 
defines a "hyperlink" which is something quite different from the object 
of the same name in Ted Nelson's theory and (separately) in Mac 
Hypercard's implementation.  Unless recommendations are to start 
creating synthetic nonsense names for the formalisms they describe, we 
are stuck with the current use of names with (hopefully) mnemonic value. 
  It is a common but irritating error to assume that a name used in a 
formalism is the same as the common usage of that name in some other field.

Elements with no prefix and no default in effect, and attributes with no 
prefix, are not in a namespace as the term is used in the formalism 
described by the Namespaces recommendation.  A programming API which 
suggests anything different is simply an erroneous implementation.

A set of related factors that can lead to confusion:

- The empty string "" is in fact a perfectly good URI reference, meaning 
"the resource in which I appear"
- it is impossible for the empty string "" to serve as a namespace name 
in the Namespace recommendation's formalism, as this empty string is a 
used as a signal to *undeclare* the default namespace - and it has been 
proposed to extend this facility to undeclare namespace prefixes as well.
- it turns out that in a programming library, it is perfectly reasonable 
to use the empty string "" as a signal that no namespace is in effect. 
Note that it would also be perfectly reasonable to use a NULL or null 
string (in C or Java terms) or some other string that can't be a URI, 
e.g. ":".  The use of "" for this purpose (which I helped argue into SAX 
against those who wanted to use null) is awfully convenient because it 
allows a bunch of common things to be based on string comparison 
operations.  However it is confusing because it supports a fuzzy line of 
thought along the lines of 'since "" is the URI ref to the current 
document, obviously the unprefixed stuff is in the "default namespace" 
of the current document' which, while sweet on the mental tongue, finds 
no support in the namespace recommendation.

  -Tim


-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org> , an
initiative of OASIS <http://www.oasis-open.org> 

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl> 
Thread:
John Cowan
Marcus Carr
Eric Bohlman
Marcus Carr
james anderson
james anderson
james anderson
Marcus Carr
Arjun Ray
Marcus Carr
Arjun Ray
John Cowan
Arjun Ray
John Cowan
Arjun Ray
John Cowan
Arjun Ray
John Cowan
Deborah Aleyne Lapeyre
John Cowan
Thomas B. Passin
Ronald Bourret
Ronald Bourret
Michael Kay
Thomas B. Passin
james anderson
David Carlisle
james anderson
David Carlisle
james anderson
David Carlisle
james anderson
Michael Kay
james anderson
David Carlisle
Tim Bray
Ronald Bourret
Ronald Bourret
Ronald Bourret
Arjun Ray
John Cowan
Arjun Ray
John Cowan
Arjun Ray
John Cowan
John Cowan
james anderson
John Cowan
Rick Jelliffe
Arjun Ray
John Cowan
Rick Jelliffe
Rick Jelliffe
Dennis Sosnoski
John Cowan
Dennis Sosnoski
John Cowan
Dennis Sosnoski
Arjun Ray
G. Ken Holman
John Cowan
Arjun Ray
james anderson
Arjun Ray
John Cowan
Arjun Ray
Rick Jelliffe
John Cowan
Arjun Ray
John Cowan
John Cowan
james anderson
John Cowan
james anderson
james anderson
John Cowan
james anderson
james anderson
John Cowan
Ronald Bourret
Ronald Bourret
Jonathan Borden
Ronald Bourret
Michael Fuller
John Cowan
Bob Hutchison
james anderson
Thomas B. Passin
John Cowan
Ronald Bourret
John Cowan
Thomas B. Passin
Ronald Bourret
Ronald Bourret
james anderson
Norman Walsh
K. Ari Krupnikov
John Cowan
John Cowan
K. Ari Krupnikov
John Cowan
G. Ken Holman
Ronald Bourret
Rick Jelliffe
John Cowan
Marcus Carr
G. Ken Holman
John Cowan
Michael Fitzgerald
Paul Prescod
John Cowan
John Cowan

Privacy Policy | Email Opt-out | Feedback | Syndication
© ActiveState Software Inc. All rights reserved