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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: Internal subset equivalent in new schema proposals?

[ Lists Home | Date Index | Thread Index ]
  • From: Paul Prescod <paul@prescod.net>
  • To: XML Dev <xml-dev@ic.ac.uk>
  • Date: Mon, 30 Nov 1998 11:23:09 -0600

John Cowan wrote:
> 
> Paul Prescod scripsit:
> 
> > That's fine, but it isn't clear why XML must be able to support directed
> > graphs at its most basic level.
> 
> Because all the world isn't a hierarchy, and sometimes the hierarchical
> aspect of things is its least important aspect.  

No, not all of the world is a hierarchy, but there is something to be said
for supporting different data models in different logical levels.
Separating them out allows you to think them through better and do a
better job (e.g. XPointer vs. ID/IDREF).

> Obviously, anything
> that is supported in the core could be migrated to an outer layer,
> as we are seeing with schema languages.  Indeed in a sense ID/IDREF
> support is not in the *core* core, because NVPs don't have to
> recognize them.

Another good reason to ignore them and use something at the XPointer
level.

> > We also know that one of the requirements for supporting directed graphs
> > *properly* is the ability to do relative addressing (that's why we have
> > XPointer).
> 
> I don't agree, unless proper support is equated with support that is
> robust against change, which is a Good Thing, but not the Only Good
> Thing.  Sometimes crude and fast is better than general.

If XPointer is widely supported, it will be just as fast to use an
XPointer. You can make it crude if you want, also.

> > ID/IDREF also has a very inflexible
> > namespace mechanism. Strictly speaking it is "enough" in that every
> > element is addressable, but practically speaking it does not allow us to
> > express the structure explicitly enough.
> 
> IMHO IDs should never carry semantic information: they should always
> be arbitrary unique values.

If I have an element that teaches a topic, and I give it an ID, and then I
delete that chapter, but there is another chapter that could also teach
the topic, shouldn't I be able to transfer the ID? (XML does not let me do
it if the new chapter already has an ID.) Obviously, my choice of new ID
for the second element is not arbitrary.

Anyhow, whether names are arbitrary or not, the real problem is that there
is only one ID namespace when we really need many of them. IDs name an
element, but elements can need multiple names, just as anything else can.

 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself.
 http://itrc.uwaterloo.ca/~papresco

Christmas shopping in a T-Shirt? Toto, I have a feeling we 
aren't in Canada anymore.

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