Element vs. mixed content (Was Re: RS/RE, again (sorry))

[ I keep changing the Subject: line because this discussion is *not*
  about RS/RE, and never really was... ]


bosak@atlantic-83.eng.sun.com (Jon Bosak) wrote:

> I'm finding it hard to
> visualize a situation in which I would want to address something based
> on pseudo-element relationships rather than "genuine" tree
> relationships.

You probably never would do this "by hand", but your software
might want to do so on your behalf.  For example, suppose you're
reading an XML document in a GUI browser and want to add an
annotation at a specific point in the document.  One way a browser
might implement this is to create a HyTime location ladder
pointing to the element, range of elements, or span of data
that you've selected with the mouse.

In this case it doesn't matter whether your browser includes
or discards whitespace in element content -- treeloc and
pathloc work for any grove plan -- as long as it parses
the document the same way every time.  You only run into
a problem if you want to share your annotations with somebody
else whose software uses a different grove plan (i.e.,
your browser discards whitespace in element content and
theirs doesn't, or vice versa.)

> It's easy to imagine cases where I would want to refer
> to the TITLE descendant of my ancestor CHAPTER, for example,

This is basically how TEI XPTRs work.  In this sense they
are more robust than treeloc since they will locate the same
element regardless of the grove plan (assuming it includes ELEMENT
nodes, of course...)

>  Is this one of those cases where 90
> percent of the complexity we're worrying about is being caused by a
> feature that in practice is used .001 percent of the time?

Quite possibly.



--Joe English

  jenglish@crl.com

Received on Wednesday, 18 December 1996 14:01:30 UTC