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

["Jason Diamond" <jason@injektilo.org>]

Hi, Michel.

> There are 2 ways to consider occurrences and associations.
> 1) As having something to do with topics.
> 2) As topics themselves.

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?

> > If I want a set of variant names to be applicable across
> different scopes,
> > do they have to be repeated in the <baseName> element that
> > contains each of
> > these scopes? Or are the variant names declared in the
> unconstrained scope
> > used as a fallback when no matching parameters are found in a specific
> > scope?
>
> Variant names are inside a given scope. They are really nothing
> more than a
> way
> to say: if you use a display device that can't display more than a certain
> number of characters,
> this is what to use. Variants should not be used to represent for example
> names in different
> languages, because they fall into different basenames with
> different scopes
> instead.
>

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.

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.

> > 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? ;-)

Thanks,
Jason.


------------------------ Yahoo! Groups Sponsor ---------------------~-~>
eGroups is now Yahoo! Groups
Click here for more details
http://click.egroups.com/1/11231/0/_/337252/_/981877927/
---------------------------------------------------------------------_->

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

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