RE: [xtm-wg] XTM 1.0 AG Review Specification

["Michel Biezunski" <mb@infoloom.com>]

> 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