[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] My report on experiments with unused namespaces
- From: Amelia A Lewis <amyzing@talsever.com>
- To: Pete Cordell <petexmldev@codalogic.com>
- Date: Wed, 22 Sep 2010 14:58:41 -0400
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.
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
well-formedness).
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
validation.
Amy!
--
Amelia A. Lewis amyzing {at} talsever.com
Love?
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]