RE: [xtm-wg] Pete J's alternative xmtdoc packaging proposal

[Peter Jones <peterj@wrox.com>]

Kal,

According to what you say below I have not misrepresented your proposal at
all!
See replies inserted below.

Peter

-----Original Message-----
From: Kal Ahmed [mailto:kal@ontopia.net]
Sent: 07 November 2000 18:07
To: xtm-wg@egroups.com
Subject: RE: [xtm-wg] Pete J's alternative xmtdoc packaging proposal


Peter,

Your proposal *seriously* misrepresents my original proposal and I feel that
it is necessary to clear up one or two points.

You state:
"there is no way to determine successful re-mapping other than by hoping.
For example, imagine that my topic map
contains sets of ID values like these:
- ...id="myid-NNNNNNN" where N is a numeral.
- ...id="pre-myid-NNNNNNN"."

and go on to give an example of a processor that inserts 'pre-' in front of
the first id and not the second.

Let me disabuse you of that notion.

If two ids are in the same topic map, the packaging process inserts 'pre-'
in front of both id values...no name clash.

[pj] *unless it fails* at the very point before it gets to the second group
of ids. (those ids were representative of groups of ids within the
document.) this was *precisely* the point I was making.
The failsafe in the my proposal was that you hold the location first (write
it to a log or into the topic structure I outlined as a T-Loc) so that
subsequent failure can be detected. If you haven't got the location you
haven't touched anything yet, so you can just have the processor pick up
where it left off.

If the ids are in different topic maps in the package, then the process
inserts 'pre-' in front of the first and some other prefix (e.g. 'foo-') in
front of the other. 

[pj] yes. i know.

Your name clash will only happen if an empty string is
selected as the prefix value. 

[pj] no. see above and below.

However, my proposal does contain one, far
smaller, flaw which is that given ids  'cd' in one topic map and 'bcd' in
another, if the first receives prefix 'ab' and the second 'a', we can
generate a name clash. However, this is easily forstalled by requiring a
separator '.' to appear between the prefix and the original value. 

[pj] this was precisely the point I was getting at with the failure
argument, BUT i was *only* concerned about it in the case of failure. IN
THAT CASE, the separator is not enough because you haven't looked at the
values to determine whether there already is one in some ids in the doc.

So we
would get ab.cd and a.bcd (note that a, b, c or d can be replaced by a '.'
and the name clash will not occur - we have now limited the potential for
clashing to the possibility that all ids are generated as a string of '.'
characters).

On a related note, your packaging proposal requires that the packaging
process be able to generate some unique, 'ugly' ID. ["When all the documents
have been scanned ID clashes are determined and for any ID clashes one of
the two IDs that clash is re-mapped to a completely new value."] How can you
guaruntee that this new value will not clash ? Without holding all of the
encountered IDs in the process-space, you can't. It implies a huge overhead
for processing a usefully large topic map.

[pj] not quite sure what you mean here. I stressed in my proposal (at least
I hope I stressed enough) that the packaging processor was not the TM
processor. It scans all the ID values and, YES, it does hold them all in its
memory or log file for the duration of the packaging process -- but it holds
*only* IDs and their locations. When clashes are re-mapped only one of any
two values that clash is given a new value. The topic map structure that I
outlined to hold this data is written out in the topicmap element purely as
a string with the necessary syntax in it.

[pj]if you are talking about when this package gets into the TM processor,
what is to stop you unmapping the values if that is what you want to do in
your processor? in both proposals there will have to be some global checking
of IDs when merger occurs anyway, and I understand that clashes that are
other than those recorded may arise here. but in your proposal it seems you
are not bothered about the existing id values and in mine I am for the
reasons I stated with the mirroring use case. that is all.

So, the rhetorical question : "If Ahmed's method checks all ID values first
in order to avoid the above then why not just re-map the specific values
that clash." is answered "Well, actually it doesn't need to do that. In
fact, the whole purpose is that you *don't* have to do that."

You make some spurious point about the packaging process failing. This is
completely bogus as software failure is a software problem, not a
specification problem. It is just as likely that **any** process writing XML
could fail and generate invalid XML.

[pj] i don't see it as being a spurious point for 'usefully large' topic
maps. the capacity for transaction logging rollback is good for any extended
processing.

As for the addition of syntax, see the latest version of the XTM dtd posted.
Alot of problems are solved by additional syntax.

[pj] more syntax. yeah.

 The syntax that I am
proposing is a minimal amount required to (IMHO efficiently) solve the
stated problem of topicmap packaging.

Regards,

Kal


> -----Original Message-----
> From: Peter Jones [mailto:peterj@wrox.com]
> Sent: 06 November 2000 10:59
> To: Sam Hunting (E-mail); Murray Altheim (E-mail); 'xtm-wg@egroups.com'
> Subject: [xtm-wg] Pete J's alternative xmtdoc packaging proposal
>
>
> Hi,
>
> Following the news that I would not be coming to Dallas, Sam
> asked me to put
> together a more coherent statement of my proposal for xtmdoc packaging.
>
> Here it is. (The .zip contains a html page and a couple of jpegs.)
>
> (Murray, If you could put this on your magic doctypes site
> without incurring
> significant injury to yourself, that would be great. Thanks.)
>
>  <<PPJ_PackagingProposal_X.zip>>
>
> Enjoy!
>
> Peter
>
> Peter Jones
> mailto:peterj@wrox.com
> Wrox Press - Programmer to Programmer (TM)
> http://www.wrox.com
> http://www.wroxconferences.com
> http://p2p.wrox.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 -------------------------~-~>
Create your business web site your way now at Bigstep.com.
It's the fast, easy way to get online, to promote your business,
and to sell your products and services. Try Bigstep.com now.
http://click.egroups.com/1/9183/1/_/337252/_/973684496/
---------------------------------------------------------------------_->

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

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