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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: Another errata?

[ Lists Home | Date Index | Thread Index ]
  • From: Mark Birbeck <Mark.Birbeck@iedigital.net>
  • To: XML Dev <xml-dev@ic.ac.uk>
  • Date: Tue, 2 Feb 1999 23:51:27 -0000

John Cowan wrote:
> Mark Birbeck wrote:
> > How not quite? A namespace is a set of unique entries *by 
> definition*.
> > That's what they are - a set of unique entries. You can't 
> have a 'set of
> > unique entries' that contains a duplicate.
> 
> That is not the definition of "namespace" used by REC-xml-names.
> Clause 1 specifically denies that XML namespaces are sets.

Clause 1 refers to the definition of 'XML namespace', which, as you
rightly say, is not a set. But as I understand it an 'XML namespace'
comprises numerous 'namespaces' (in the sense in which I used it) which
each DO have unique entries, because they *are* sets. My understanding
of the motivation for this is that if a single 'namespace' (i.e. set)
was used then we would lose contextual information about a name. We
therefore partition them in order to preserve this information. An 'XML
namespace' is therefore a 'namespace container' that is not itself a
'namespace'. Clause 1 seems to put the emphasis on the presence of
structure, rather than the lack of uniqueness.

> > >  An element can have the same name as a global
> > > attribute without problem.
> > 
> > True. But they are not in the same namespace. According to A.2 the
> > element would be in the 'all element types' partition, and 
> the global
> > attribute would be in the 'global attribute' partition.
> 
> They are in separate partitions of the same namespace.

No again - they are in separate partitions of the same 'XML namespace'.
Each partition is itself a namespace. A.2 has it that:

".. we identify the names appearing in an XML namespace as belonging to
one of several disjoint traditional (i.e. set-structured) namespaces
..."

> Appendix A says that unprefixed attributes are assigned to one of the
> per-element-type partitions of the namespace.  It also says that
> unprefixed attributes are assigned to "associated namespaces".

Nothing wrong with that. Each element appears by name in the 'all
elements type' partition. However, each element also has its own
partition - a 'per-element-type' partition - into which are collected
all the unqualified attributes for that element. This PET partition is a
true 'namespace' (in the sense I used it) because from XML 1.0 we know
that we cannot have duplicate attributes on an element. And that is why
the spec refers to it as an 'associated namespace' - associated to the
element.

> Clause 5.3 is not involved and I shouldn't have dragged it in.

I see.

> But none of this matters much because Appendix A is not normative.

I suppose so. But it does help to understand what it is that is making a
particular element or attribute name unique with the entire document. I
particularly think that the expanded attribute stuff is very useful.

Mark Birbeck
Managing Director
Intra Extra Digital Ltd.
39 Whitfield Street
London
W1P 5RE
w: http://www.iedigital.net/
t: 0171 681 4135
e: Mark.Birbeck@iedigital.net


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)





 

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

Copyright 2001 XML.org. This site is hosted by OASIS