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

[Peter Jones <peterj@wrox.com>]

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

-------------------------- eGroups Sponsor -------------------------~-~>
Last minute trips at  
first-rate discounts 
from Hotwire.
http://click.egroups.com/1/9748/4/_/337252/_/972040478/
---------------------------------------------------------------------_->

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

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