[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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 -------------------------- eGroups Sponsor -------------------------~-~> eLerts It's Easy. It's Fun. Best of All, it's Free! http://click.egroups.com/1/9699/4/_/337252/_/972392550/ ---------------------------------------------------------------------_-> To Post a message, send it to: xtm-wg@eGroups.com To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC