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

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

>
> Kal wrote:
>
> "As I understand it, you are creating just one association (lets call it
> 'id-remappings') between two associations ('old-values' and 'new-values'),
> and that occurrences in old-values and new-values are scoped so that a
> precise one-to-one relationship is maintained. So you still end up with a
> requirement for a distinct scope definition for each id value clash."
>
> [pj] one assoc between two topics... but, Yes.
>
> Is there something that I'm missing here, because this seems to
> impose some
> fairly substantial overhead. The only possible benefit I can see is that
> there is no new syntax, but the semantics of the processing you suggest to
> me seem a lot more heavy than the burden of processing a couple of extra
> tags (which are restricted to the xtmdoc content model and so an
> application
> could choose to not implement xtmdoc or its associated management elements
> and only implement topicmap and its subelements).
>
> [pj] but in your model the prefixes on id values are not restricted to the
> xtmdoc content model, they are throughout the doc, if I have
> understood you
> correctly.
> This is an implementation issue, and I bow to your superior
> experience here.
> However, there are arguments (like weighing in with Moore's Law)
> to suggest
> that that shouldn't be such a critical thing.
>
> In one sense there is truth in what you say about the semantics of
> processing. However, in my latest packaging proposal the creation of the
> *syntax* that expresses this is not heavyweight, so that doesn't really
> count. Next,
> the percentage of IDs in a given set of maps that clash is likely to be
> small, of the order of less than 1% on average, I would guess.
> So the processing overhead is something that you would have to
> put into the
> TM engine anyway, and it adds a small load to 1% of the link
> calls/ends that
> enter the map from outside, and two topics and two assocs to the map.
> Big Deal.
>

Perhaps not a big deal on my monster laptop, but definitely a big deal on a
PDA and more importantly its a more complex process to explain to a
programmer how to code. (I have experience of trying to tell programmers
what to do too and believe me, you and I understand it but I would be
willing to bet that neither of us could explain it to Joe Java Programmer
and get code that comes remotely close to our intentions...and Moores Law
does not apply to programmers ;-). To me, making the packaging process as
simple as possible is the really Big Deal. I like your suggestion - it has a
lot of extensibility to it. But it strays too far (for my liking) from the
XTM/XML KISS principle.

> Your method has to remap the link calls/end that enter the map
> from outside
> for every call made to every ID...forevermore.

1) This is a packaging **interchange** format. Forevermore == until it has
been read and unpackaged by the receiver.
2) The remapping is a straightforward string manipulation which involves one
additional lookup **per topicmap**.

> If I package that package
> inside another package what happens to those links that still enter the
> result from outside? And so on...

Whoa! The content model of xtmdoc does not include another xtmdoc. So
additional packaging only comes by adding topicmaps to an existing xtmdoc.
If you do this, then there is no problem as long as you ensure that the
relatively small space of prefix strings remains unique...and if you have a
problem with clashing prefixes when moving a topicmap from one package to
another (and I can only imagine this happening in the (to my mind spurious)
"cutting-and-pasting-in-emacs" scenario), a quick search-and-replace should
fix this.

Cheers,

Kal
>
> best
> Peter
>
> -----Original Message-----
> From: Kal Ahmed [mailto:kal@ontopia.net]
> Sent: 27 October 2000 13:31
> To: xtm-wg@egroups.com
> Subject: RE: [xtm-wg] An way to avoid id clashes (WAS: Merging proposals
> u ploaded)
>
>
> >
> > 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'.
> >
>
> As I understand it, you are creating just one association (lets call it
> 'id-remappings') between two associations ('old-values' and 'new-values'),
> and that occurrences in old-values and new-values are scoped so that a
> precise one-to-one relationship is maintained. So you still end up with a
> requirement for a distinct scope definition for each id value clash.
>
> Is there something that I'm missing here, because this seems to
> impose some
> fairly substantial overhead. The only possible benefit I can see is that
> there is no new syntax, but the semantics of the processing you suggest to
> me seem a lot more heavy than the burden of processing a couple of extra
> tags (which are restricted to the xtmdoc content model and so an
> application
> could choose to not implement xtmdoc or its associated management elements
> and only implement topicmap and its subelements).
>
> > (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
> >
> >
> > 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/_/972666938/
---------------------------------------------------------------------_->

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

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