Re: [xtm-wg] Syntax is a bitch :-(

["W. Eliot Kimber" <eliot@isogen.com>]

Dave Pawson wrote:

> For a topicmap that is regularly updated, using xslt generate-id()
> for id's, the same problem exists, as Ken Holman pointed out recently.
> 
> My problem centres around automatically generated topics,
> but assocs manually generated, which then use the id values.
> One more run through as I add another topic, and all my
> assocs are no longer valid. Thats why I would prefer CDATA values
> to identify the topics, as apposed to ID attributes.

This case is no different from the general "new version of document with
references to it" use case (that is, the normal case of revising a
document to which links have been created).

The only way to solve this problem is to interpose some form of
indirection between the references and the things referenced
("referents" in the terminology of the paper that Steve N., Peter N.,
and I presented at XML '99 on version managementof hyperlinks). This
indirection protects the initial reference from changes in the location
and properties of referents. It is up to the reviser of the referents to
provide new instances of the indirections. The only other option is to
revise every referring document whenever its targets are revised. This
is clearly unworkable in the general case (because a change to any given
document could imply changes to all other documents in the system).

Note that once you have this indirection and some infrastructure to
manage it, it is straightforward to rewrite the indirect pointers to
point to newly-generated IDs, so that the fact that IDs are re-generated
with every revision becomes a non issue. But note also that the pointers
could be by tree location and be just as reliable--that is, the
requirement is to map the original address, whatever its form, to the
new address, whatever its form. It is just as easy to calculate the tree
location of a topic in its containing document and map that to the tree
location of corresponding new version of the topic in the new version of
the topic map document.

Note that if you throw away the original topic map document when you
create the new version, it *appears* that using IDs that persist across
versions will help. But note that what you're really doing is using the
location of the containing document as your indirection by transparently
changing its value from being the original document (which you've now
thrown away by overwriting it with the new version) to being the new
version (which is a different document than the original version). But
this approach completely disallows maintaining old versions of topic
maps, which is absolutely a hard requirement in many, if not most,
information management scenarios. For example, if my topic map reflects
legal analysis, I most definitely need to know what the state of that
analysis was at any point in time, not just now. 

These issues are not unique to topic maps in any way--they are general
to all uses of pointing in XML documents. The Topic Map specs cannot do
anything by themselves to help solve the problem because the problem
does not have a syntactic solution. But the Topic Map standard should
not impose the requirement to put IDs on all topics as that does not
help at all and only forces conforming systems to add data to documents
they may not need or want to add. At the same time, the Topic Map
standard must not disallow the use of IDs by those who want to.

Cheers,

E.
-- 
. . . . . . . . . . . . . . . . . . . . . . . .

W. Eliot Kimber | Lead Brain

1016 La Posada Dr. | Suite 240 | Austin TX  78752
    T 512.656.4139 |  F 512.419.1860 | eliot@isogen.com

w w w . d a t a c h a n n e l . c o m

-------------------------- eGroups Sponsor -------------------------~-~>
Tellme Sports. Tellme Stocks. Tellme News. Just Tellme.
http://click.egroups.com/1/9530/4/_/337252/_/971185268/
---------------------------------------------------------------------_->

To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com