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

[Peter Jones <peterj@wrox.com>]

This depresses me a lot:
http://www.w3.org/TR/xlink-naming/

another reason I like the 'Namespace' topics approach is that 
you can colour the same item in your document with more than one namespace,
and which glass you choose to look at your things through for a given reason
is up to you.

Call me a [#censored!#] for even daring to suggest such things, but I like
the way a TM-metadata processor could (in theory) do this.

Peter


-----Original Message-----
From: Peter Jones [mailto:peterj@wrox.com]
Sent: 24 October 2000 14:05
To: 'xtm-wg@egroups.com'
Subject: RE: [xtm-wg] An way to avoid id clashes (WAS: Merging proposals
u ploaded)


Hi Kal,

I just wanted to address the two issues that you raised earlier in this
discussion:

<Kal>
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.
</Kal>

I admit that I didn't really understand this. I thought you were saying that
there was some subtle difference between XTM ids and 13250 ones. 13250 says:

<!-- The attribute form "HyTime common attributes"
(common) declares the HyTime attributes shared by all
topic map forms. -->
<!attlist
-- Common --
-- HyTime common attributes --
-- HyTime Clause A.5.2, 7.8 --?ISO/IEC 13250:1999(E) © ISO/IEC
#ALL
id -- Unique identifier --
ID
#IMPLIED -- Default: None --

In any case my proposal doesn't care what the data type is and doesn't
interfere with existing definitions.


>2) You have the 'overhead' of one assoc. structure per remapping.

Not true. 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.
...Or something like that.


But the one thing I like about my proposal the most, is that it is
extensible to cover all sorts of other namespace information. So my
'Namespace' topic could also, e.g., have occurrences that point to topics
that linked all aspects of the topicmap governed by the 'scoping'
information in an XML Namespace. So I could do mergers that were packaged
and sent to someone who could redefine one or more of the namespaces if they
wanted to, without expensive tag prefix processing. And so on...

I realise that the exact issue of topic names and scopes needs to be more
clearly defined if we open the door to the idea of generic namespace
information storage. But in the single case of id clash remappings I don't
think the task is too onerous to rule out consideration of the proposal.

If anyone else likes this idea, can I suggest that we might move the
Namespace public topic further up the list in Michel's notes
  http://www.doctypes.org/xtm/org/minutes20001013.html
Public Subjects To Be Defined in the XTM Spec:
from category 3 to 2 or even 1.

Am feeling bullish today.

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

-------------------------- eGroups Sponsor -------------------------~-~>
eLerts
It's Easy. It's Fun. Best of All, it's Free!
http://click.egroups.com/1/9699/4/_/337252/_/972642733/
---------------------------------------------------------------------_->

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

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