illegal namespace usage

[Simon St.Laurent]

At 05:11 PM 8/9/99 -0700, Lisa Rein wrote:
>Simon St.Laurent wrote:
>
>> I've concluded that namespaces itself is a great idea.  I've also concluded
>> that integrating it with XML 1.0 in any reliable way is pretty much
>> impossible.  
>
>Please explain this statement. 

Sure - piece of cake.  I think we've been over these issues a few hundred
times, but no problem.  (I really do hope I'm not reminding the list of
some of its more frightening days in any troubling way.)

Namespaces are already in use all over
>the place-- the implementation-specific behavior of among different
>processors might vary,  but the integration of namespaces w/XML ver 1.0
>doesn't appear to be "impossible", and certainly isn't the culprit for
>the inconsistencies between the different "namespace aware"
>applications.   
>-- XSL and XSLT namespaces are currently being used all the time
>-- HTML namespaces are being "used reliably" in IE5 
>-- Even RSS's erroneous RDF namespace declaration does nothing reliably 
>every time :-)

Namespaces are processed just dandy right now by a lot of applications.
But none of those applications is beginning to stress out namespaces.  None
of them are dealing with XML validation in a context where prefixes have
conflicted and needed to be changed to something other than what's in the
DTD, for example. None of them have attempted the legal but difficult
problem of namespaces being declared in default attributes, which may or
may not actually get processed in non-validating parsers.

Basically, none of these applications is really doing anything exciting
that couldn't have been done just by focusing on the prefix.  While
(hopefully) they do check beyond the prefix, none of them has explored the
terra incognita that's out there.

Particular applications do use namespaces reliably.  That doesn't mean that
all possibilities opened by the spec can be used reliably.

>Simon St.Laurent wrote:
>> Section 5.3, Uniqueness of Attributes, makes it
>>  > illegal to have two attributes for an element that have identical
>>  > qualified names, never mind the prefixes.
>>  > 
>>  > How should XML processors handle these errors? 
>
>they should "break", and give error messages like any other error.  It
>sounds like the document in question would be violating both XML v 1.0
>Rec and the Namespace Rec...
>
>what other behavior did you have in mind?  it's probably an oversight or
>a typo in the document more than (what could amount to) an intentional
>design flaw someone had intentionally integrated into their syntax --
>you're not doing anyone a favor looking the other way.

I agree that they should break - it's just that that behavior isn't in the
spec.  Assuming that such things are obvious doesn't seem consistent with
the approach XML 1.0 took, describing error behavior (well-formedness and
validation) in detail.

>There's probably a better, less-ambiguous, more descriptive name for
>that attribute's second occurrence (within the same element)
>or, maybe that piece of as-yet-unaccounted-for information is a hint you
>should place that value as an attribute of another nested element.
>
>either way, whatever you're trying to do, ambiguity isn't going to help
>you.  That "no duplicate attribute names within the same element rule"
>just seems like a good "rule of thumb".    i think that's all the specs
>are trying to say there.  (although i'm feeling very foolish now for
>attempting to speak for the editors of either recommendation :-)  

I don't object to the rule of no double attributes at all.  I object to the
fact that this recommendation doesn't provide any guidance on what such a
violation means.  Is it a problem on a level with its XML 1.0 equivalent,
making the document not well-formed (and processing should stop) or is it
just another error to report and processing continues?

The rules make sense (though I'm not convinced about this no default
namespace for attributes thing) - it's just that unlike XML 1.0,
enforcement is left entirely to the discretion of various random tool
writers, making it difficult to assume that namespace processing will be
performed consistently across different processors.

Genuinely integrating the two recommendations - possibly with the Infoset
as David Megginson suggested - might finally put these issues to rest.
Until then, they'll be lurking in the background.

Simon St.Laurent
XML: A Primer (2nd Ed - September)
Building XML Applications
Inside XML DTDs: Scientific and Technical
Sharing Bandwidth / Cookies
http://www.simonstl.com

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)