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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: Comments on Section 2.6 of XML-Namespaces

[ Lists Home | Date Index | Thread Index ]
  • From: Andrew n marshall <amarshal@usc.edu>
  • To: "'Rick Jelliffe'" <ricko@allette.com.au>, "xml-dev@ic.ac.uk" <xml-dev@ic.ac.uk>
  • Date: Tue, 31 Mar 1998 16:27:30 -0800

On Monday, March 30, 1998 10:06 PM, Rick Jelliffe 
[SMTP:ricko@allette.com.au] wrote:
>  I think it is important to know that the namespace mechanism does not
> attempt to solve all problems with sticking names into schemas.
> All it does is bundle names with a comon prefix into a bag with a name
> (the "ns" attribute") and then point to some other resource which
> may contain some interesting information about the schema.

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"


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