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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] My report on experiments with unused namespaces

On Wed, 22 Sep 2010 18:54:10 +0100, Pete Cordell wrote:
> Original Message From: "Amelia A Lewis"
>> On Wed, 22 Sep 2010 17:49:39 +0100, David Carlisle wrote:
>>> It is well formed. (and parsed as such by any xml parser I've tried).
>> YAY!  Outbreak of sanity on xml-dev.  News at eleven.
> I use this forum to further my understanding, not to be insulted, so I won't
> be debating this further with you.  Please setup your e-mail client 
> to filter out my e-mails if my posts are too stupid for you.

If you found my comment insulting, I apologize for my tactlessness.  It 
was not, in fact, intended to cause offense, to you or to anyone else.

David is correct, however.  No matter how much one would like to make 
use of colon in a name that isn't a QName or use of xml as the start of 
a name into well-formedness, or even mere validity errors, they are 
not.  They are "reserved."  By the same token, though random strings or 
numbers are not URIs, unless they're "relative URIs", which are 
deprecated, using them does not violate a constraint for validity or 

Well-formedness is defined by the XML recommendation (supplemented by 
the Namespaces in XML rec).  For DTD-governed dialects, the same recs, 
and the DTD determine validity and violation of validity constraints.  
It is possible to go through the XML and Namespaces recs and collect 
the complete list of WFC and VC assertions.  (For dialects governed by 
Schema, the task is somewhat more formidable, but you can find all the 
various ..C assertions in the two schema specs).

Things like XML:Base and XML:ID effectively change the rules for 
validity ... but not, I think, for well-formedness (I believe that the 
only domain-specific well-formedness constraint is namespace 

It's important to distinguish between things that are called errors and 
things that the spec authors weaseled around.  It's useful, in the 
context of weaseling, to examine current practice; if the spec authors 
found themselves unable to reach a consensus that would designate some 
behavior as "incorrect" (something about which an RFC 2119 keyword 
assertion might be made), then any behavior is probably acceptable, but 
the "least surprising" will be doing what other implementations do.

We started this thread with a concept of "namespace in use" which does 
not correspond to a well-formedness or validity constraint.  The 
discussion expanded to include, among other things, the use of 'xml' as 
the start characters of a name, the use of colons in names (both noted 
by the XML spec as "reserved"), and the use of relative URIs (random 
strings that aren't actually URIs and can't be decomposed into a 
scheme-part and a hier-part) (which is noted as deprecated).  Without 
an assertion in a spec that uses RFC 2119 keywords, it is wrong to 
consider violation of these reservations and deprecations as errors.

It is still more incorrect to pose it as: reserved means you can't use 
it, so it's invalid, and therefore not well-formed.  That runs too many 
"terms of art" within the XML technical community into a single 
concept.  Well-formed is fundamental; an ill-formed document can't be 
parsed.  Validity is optional, and may not be determined (if you don't 
validate).  Consequently, no validity error should ever be regarded as 
fatal, to the parser.  Reservations and deprecations do not require 
validation, but likewise are not characterized as well-formedness 
constraints ... so they're non-fatal, like VCs, but do not require 

Amelia A. Lewis                    amyzing {at} talsever.com
A joke, that.  Love was the problem, not the solution.  Being hit by a
car was better than love.
            -- Steven Brust, PJF, "Cowboy Feng's Space Bar and Grille"

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS