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

[Peter Jones <peterj@wrox.com>]

I thought I addressed this problem earlier. I'll be clearer about what I was
getting at...

You have some topicmaps (the content of several <topicmap> elements ) for
packaging in an xtmdoc wrapper element.
You get the docs and fire up the outer packaging pre-processor (note that i
didn't say TM processor)
It:
1)scans all topicmaps and notes clashes of IDs. since each subset could be
parsed separately at this stage you could do:
-scan [SAX parse]
<xtmdoc>
   topicmap number one in here...
<xtmdoc>
note ID values.
-scan [SAX parse]
<xtmdoc>
   topicmap number two in here...
<xtmdoc>
note ID values.
...etc.
-assess value clashes

2) If there is a clash, rewrites one of the values with a new one, at the
same time holding on to the info of where the new value was inserted, and
what the old value was in the memory of the packaging pre-processor.

3) Package the n topicmaps in a single xtmdoc wrapper

4) At the same time the info from the outer processor is written into some
TM syntax that is inserted in the document in a fashion I proposed earlier. 

<insert-from-previous-mail>
I define one assoc of type 'clash_remappings' per topicmap
included in the package and one topic for old values and another for new
values and assoc the two, then there is nothing to stop me simply loading
the values to be mapped into scoped names, with one scope per mapping pair
across the two topics.
So I have my 'Namespace' public topic, that then points to an assoc of a
type (public also?) that has as endpoints the two ends of a mapping between
two values, each mapping pair in a separate scopes.
</insert-from-previous-mail>
I would add to this that one of the two topics in the 'clash_remappings'
assoc needs to have as an occurrence, the location of the ID that was
'corrected'.

(I think that whether this needs to be inserted inside the separate topicmap
elements or within a separate topicmap element in the overall package is to
be decided.)

5) Validate the whole xtmdoc 

6)...and put the output into the TM processor if you want to.

Is that any help?

Peter


-----Original Message-----
From: Kal Ahmed [mailto:kal@ontopia.net]
Sent: 27 October 2000 12:06
To: xtm-wg@egroups.com
Subject: RE: [xtm-wg] An way to avoid id clashes (WAS: Merging proposals
u ploaded)


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

-------------------------- eGroups Sponsor -------------------------~-~>
Your family still won't know what you do.  At least they'll know where.
The resources, brainpower & breadth of opportunities at Microsoft are
unmatched. The only question is are you ready for that kind of impact?
http://click.egroups.com/1/9223/4/_/337252/_/972646233/
---------------------------------------------------------------------_->

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

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