RE: [xtm-wg] An way to avoid id clashes (WAS: Merging proposals u ploaded)

["Kal Ahmed" <kal@ontopia.net>]

There is still the syntactic problem of all of those topic map objects
having ID attributes, which *must be unique* in the xtmdoc document. Or do
we now have not only a wrapper element but a complete change of the -id-
attribute to CDATA.

The namespacing idea works nicely for the problem of readdressing the
topicmap elements, but doesn't solve ID attribute value clashes. I'm
concentrating on the syntactic here I know, but I haven't seen a suggestion
on how this syntactic constraint be satisfied.

Any takers ?

Kal

> -----Original Message-----
> From: Peter Jones [mailto:peterj@wrox.com]
> Sent: 20 October 2000 12:17
> To: 'xtm-wg@egroups.com'
> Subject: RE: [xtm-wg] An way to avoid id clashes (WAS: Merging proposals
> u ploaded)
>
>
> OK, points well taken. I do like elegance though.
>
> >
> 1) Your xtmdoc instance is no longer valid if id attributes are
> declared as
> type ID - so a parser (not a tm processor, just the plain old validating
> SAX/DOM parser that is being used as input to the tm processor)
> will not be
> happy.
> >
> In a similar fashion to your solution I was suggesting replacing any id
> string that clashed (ID or id, all the same to me in this case :) with one
> that didn't and recording the remapping, but only replacing those that
> needed to be replaced. It would still validate with an XML parser.
>
> Peter
>
> -----Original Message-----
> From: Kal Ahmed [mailto:kal@ontopia.net]
> Sent: 20 October 2000 12:02
> To: xtm-wg@egroups.com
> Subject: RE: [xtm-wg] An way to avoid id clashes (WAS: Merging proposals
> u ploaded)
>
>
> >
> > Thanks Kal,
> >
> > I did actually click last night that it worked like that, and
> > tried to send
> > you a mail to that effect but it bounced. oh well...
> >
> > OK. Then, yes, I agree that this is one way to cure the problem.
> > However, I am inclined to think that your solution has two aspects that
> > worry me:
> > 1) It is like using a pile driver to squash an ant.
>
> Well, its as simple as a piledriver, but not as heavy ;-)
>
> > 2) Writing all that information into the linking structure of
> the document
> > might risk complicating subsequent inclusions. It concerns me
> > that those id
> > strings might end up looking like UUIDs in the Web environment
> at a later
> > stage.
>
> Nothing is complex about subsequent inclusions the process would be:
> 1) Scan the 'redirect' elements for all declared prefixes.
> 2) Generate a prefix which is not any of the ones scanned in (1)
> 3) Generate a redirect element with the prefix determined in (2) and the
> base URL of the tm you are inserting
> 4) Insert the topic map element.
>
> > I seems to me to be an obvious point that folks are going to
> > start using the
> > power of topic maps to say things about topic maps at some
> point (because
> > topic maps are so wonderful that we can do lovely things like that!), so
> > a) why shouldn't we, as the standard makers be the first to do so, and
> > b) it seems an obvious consequence of this that some topics are
> > going to be
> > More Meta Than Most in this second-order topic mapping -- the concept of
> > namespace being one IMHO.
> >
> > Therefore, in light of the fact that id clashes are unlikely to be that
> > numerous, and that shoving lots of extra prefixes in possibly
> > risks muddying
> > the waters for later, could we do the following instead.
> >
> > 1)When an xtmdoc package is produced a More Meta Than The Rest topic map
> > should be included that contains the following:
> > a) A set of Namespace topics (where 'Namespace' is a Public
> Topic) one for
> > each topic map in the package.
> > b) Each Namespace topic contains the original URL of the document as its
> > identity, is of type="Namespace", and has as an occurrence the
> address of
> > the topicmap in the package. Such a Namespace topic can contain
> any number
> > of different types of namespace information (XML Namespace, ID clash
> > mappings, doc origins, &c, in different TM scopes).
> > c)Each Namespace topic also has as occurrences a set of
> associations that
> > describe the relations between any id attributes that have been
> > remapped to
> > a new value and their new values in the package in the process
> of removing
> > clashes (so the reassignment is reversible). Likewise the IDREFS.
> > d) anything else sensible that would make this proposal work
> that my poor
> > brain can't think of just now
> >
>
> I did consider it being done with another topic map, it has a certain lure
> of elegance about it. However, if I understand what you are proposing, you
> think that there should be one association for every remapping of ID and
> IDREF that you need to do. I don't like this for two reasons:
> 1) Your xtmdoc instance is no longer valid if id attributes are
> declared as
> type ID - so a parser (not a tm processor, just the plain old validating
> SAX/DOM parser that is being used as input to the tm processor)
> will not be
> happy.
> 2) You have the 'overhead' of one assoc. structure per remapping.
>
> If anything, this is more of a piledriver solution (in terms of
> weight) than
> the redirect element.
>
>
> > This way the set of remappings is minimal, and the package remains
> > relatively clean for for future mergers further down the line.
> > The remapping
> > information is also available at the topic map level, not
> internal system
> > dig down.
>
> Having the remapping information available at the tm level would
> be good, I
> agree and perhaps someone can come up with a proposal to do that. But my
> feeling is that it must address both the ID uniqueness issue and
> the minimal
> packaging overhead issue.
>
> Cheers,
>
> Kal
>
>
>
>
> To Post a message, send it to:   xtm-wg@eGroups.com
>
> To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com
>
>
> To Post a message, send it to:   xtm-wg@eGroups.com
>
> To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com
>
>
>


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

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