[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xtm-wg] XTM 1.0 AG Review Specification
> The Class Hierarchy (B.1) shows Association deriving from TopicMapNode and > Occurrence from TopicCharacteristic. Neither one is shown deriving from > Topic. Do some systems treat them as such? See section 2.2.1.2. > That's precisely what I was wondering. The second example in 3.7.3 > (<variant> Element) shows that variant names can be used to refer to not > just strings but also graphical icons and audio files (and probably any > other "displayable" resource). Let's say that I have a topic with > base names > in three different scopes. One for each of English, French, and Icelandic. > The base name in each of these three scopes is different but it's entirely > possible for a graphical icon that represents this particular topic to be > the same regardless of the language. The current serialization > syntax seems > to require each base name to contain its own variant with the #display and > #icon parameters even though the <resourceRef> would point to the same > resource for all three. This wastes space when serializing but the > equivalence of these three variants is also lost when deserialized by any > other (probably even the same) processor. This is why I wondered if the > variant could appear in the unconstrained scope and be "inherited" by the > others. There seems to be always a compromise between waste of space and clarity. I agree that what you describe is not present and that you need to repeat the variant name you want to use. It's up to the application to figure out that it's the same. Unless what you describe is made part of the templates/models, etc. which is currently being discussed. > Why does the base name have to be a string? Why can't it be a > resourceRef or > resourceData like variant names? If it's a resourceRef, determining > equivalence is easy: just compare the URIs. If it's resourceData, just > compare the bytes. It it's a string, it's like resourceData. The tag is simply not necessary because we already know it's a string. If I remember, we disallow using URIs for names to get some unambiguous basis for the name-based merging rule. It prevents applications to first having to figure out whether two resources are the same or not, which is too much to ask at that level (but is useful at others). > > > Why <roleSpec> and not just <role>? > > > > Same answer as for basenamestring. Role is overloaded. It has to > > do with the > > difference > > between the way xlink uses role and the way links are done in XTM. If we > > would have put > > role, then the question would have been: why your role is different from > > xlink:role ? > > Isn't that what namespaces are for? ;-) Yes, but humans are behaving differently from computers (sometimes!) Michel ========================================== Michel Biezunski, InfoLoom Tel +33 1 44 59 84 29 Cell +33 6 03 99 25 29 Email: mb@infoloom.com Web: www.infoloom.com ========================================== ------------------------ Yahoo! Groups Sponsor ---------------------~-~> eGroups is now Yahoo! Groups Click here for more details http://click.egroups.com/1/11231/0/_/337252/_/981886882/ ---------------------------------------------------------------------_-> 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