I'm not expecting namespaces to solve all problems. The namespace
specification is an excellent way to prevent problems when I use >>the
elements<< from someone else's DTD. This promotes the reuse of existing
DTDs, which not only saves me time, but also means that I can take
advantage of the processors written for use on the external DTDs. That is
great!!
However, I believe the namespace specification is creating more problems
than it is worth when it attempts to extend itself to individual
atteributes.
> Most elements and attributes belong to multiple schemas. This is
> both because no one schema language is good enough to define
> all the requirements that any single type has, and because of the
> symphonic, interrelated nature of the use of elements in documents.
I argee completely. That is why XML is a meta-language instead of a
specific language.
>
> So the namespace mechanism does not attempt to provide a general
> solution to all these problems. If you are interested in such a thing,
then
> the HyTime architectural forms mechanism may be of interest to you.
> (See http://www.ornl.gov/sgml/wg8/docs/n1920/html/toc.html )
> It is a far more general solution to a fairly similar problem. The
namespace
> mechanism as proposed is a minimal and modest thing, just enough to
> allow RDF and some other applications to progress, and to allow
> debate and exploration of the particular issues.
I'm sorry. I don't see any relevance between my statements and HyTime. Is
there a more specific pointer you could give me, or perhaps an example?
> 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"