Comments on Section 2.6 of XML-Namespaces

[james anderson]

the issue of 'hijacking' is orthogonal to that of naming.

in order for the example
 <Item HTML.a:href='mypage.html'>
to have any meaning, one would need to provide an attribute declaration for the
Item element. in which definition the desired relation is (re)established.
although i am at a loss as to why one would wish to perform this kind of
'deconstructive' element definition (i.e. i don't know why the wd example
  <Item T:Temp='5500'/>
matters? doesn't there have  to be an attribute list definition for Item, which
resolves the ambiguity?
remember, we're not dealing with architecture here, just names. )

if one is concerned about element / attribute integrity, then one doesn't
'hijack' attributes.
if, on the other hand, one needs to refer to attributes across namespaces, then
either qualification or mapping is necessary. the namespace wd proposes
qualification:
a) for eg., to augment attribute definitions (through definition in the internal
subset) for their use in their already defined element context one will need
unambiguous names. one could say that the namespace explicit in the element name
of an attlist has an implicit scope over the entire attlist declaration of the,
but that's not necessary
b) to specify matching criteria for a language such as xsl,  one needs to
specify the original namespace for attributes

Andrew n marshall wrote:

> > As for as your particular example goes, there is "no guarantee from the
> DTD
> > that they mean the same thing" because there is no mechanisms built
> > into raw XML DTDs to provide such a guarantee: in fact this is why
> > namespaces are needed--to make it clear that an attribute in one
> > element type is kin to another.
>
> The element declaration is that gaurantee.  XML, with the inclusion of the
> namespace specification at the element level, describes a way to trace each
> element back to an element declaration from which I can compare wether or
> not any two elements are related.  By this, I am gauranteed that the
> attributes of each element of the same element declaration have the same
> possible attributes and are complete enough to be useful with it specific
> application.
>
> However, as soon as you allow elements to be broken up into their
> individual attributes, this gaurantee goes away.  Attribute "hijacking"
> makes it impossible to maintain the relationship between attributes of a
> single element, and impossible to maintain the relationship between the
> attributes and the child elements/content.
>
> Therefore, to enable attribute to be reused, you need to group all the
> attributes and the possible child elements together.  This can be acheived
> through a form of element inheritance.
>
> > And in any case, in your particular case of hrefs, the XLink draft
> provides
> > an attribute remapping feature. So an href element
> >
> > * is attached to its element type in the Instance (& DTD)
> >
> > * is bound to a namespace by its prefix and the namespace PI
> >
> > * may be remapped to a different name by the Xlink xml:attribute
> attribute
>
> Actually, if you look at the details of the XLL spec (Part 7, second
> paragraph), attribute remapping is limited to the XLL specific attributes.
>  This is a severe limitation and I believe it should be extend to any apply
> to any attribute.
>
> > * may have additional schemas and semantics added using the
> > Architectural Forms Deinition Rquirements AFDR mechanism
> > (See http://www.ornl.gov/sgml/wg8/docs/n1920/html/clause-A.3.html )
> > which uses fixed attributes on the DTD in particular.  (Architecture =
> > schema)
>
> Thanks for the AFDR reference.  I'll try to read up on it.
>
> Andrew n marshall
>   student - artist - programmer
>     http://www.media-electronica.com/anm-bin/anm
>       "Everyone a mentor,  Everyone a pupil"
>
> 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/
> 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)




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/
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)