[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Internal subset equivalent in new schema proposals?

• From: Paul Prescod <paul@p...>
• To: XML Dev <xml-dev@i...>
• 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@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• Follow-Ups:
  • Re: Internal subset equivalent in new schema proposals?
    • From: John Cowan <cowan@l...>

• References:
  • Re: Internal subset equivalent in new schema proposals?
    • From: John Cowan <cowan@l...>
  • Re: Internal subset equivalent in new schema proposals?
    • From: Paul Prescod <paul@p...>
  • Re: Internal subset equivalent in new schema proposals?
    • From: John Cowan <cowan@l...>

• Prev by Date: Re: Why XML data typing is hard
• Next by Date: Re: XML and embedded compound data types (was "Why XML data typin is hard")
• Previous by thread: Re: Internal subset equivalent in new schema proposals?
• Next by thread: Re: Internal subset equivalent in new schema proposals?
• Index(es):
  • Date
  • Thread