[sc34wg3] Use cases for occurrence variants

[Murray Altheim]

Nikita Ogievetsky wrote:
> Murray Altheim wrote:
> 
>>Nikita Ogievetsky wrote:
>>
>>>To get occurrence variants discussion down to Earth
>>>I suggest that we try to summarize use cases.
>>>
>>>Here are those that I know of or have seen mentioned so far:
>>>
>>>Thumbnail(s) of an image.
>>>Description of an image (displayability).
>>>Alt text (displayability).
>>>Sorting occurrences (sortability).
>>>Alternate address depending on device context, protocol, etc.
>>>Model inconsistency between base names and occurrences.
>>>
>>>Any others?
>>
>>As I mentioned previously, Michel had seen the need for these and
>>proposed it originally in XTM 1.0, i.e., adding <baseName> to
>><occurrence>. It was voted down for reasons of added complexity,
>>and lack of demonstrable need. Also (if I remember correctly)
>>because occurrences in the model didn't have names, only topics
>>did.
> 
> I think that Michel had done much greater things then this.
> If he did so I am glad that we think alike.
> Per my recollection I had proposed this at the dreadful Paris meeting,
> and it was not "voted down", but postponed ("tabled" or whichever is the
> right word for it). There might be something that I am missing.

I remember it perhaps differently then. We discussed many of these
issues at quite some length, some in email, some in very extensive
telephone conversations (Sun's bill ran to something like $3000 in
less than a week of calls), and then of course in our face-to-face
meetings. XTM 1.0 was thought through in great detail, and each
decision was made explicitly, not simply by some accident.

>>If we add <baseName> to <occurrence> one could then argue we should
>>likewise (for consistency' sake) add <baseName> to <association>
>>too.
>>
>>The solution to my mind is still that if one considers an occurrence
>>as something to be talked about in its own right, to be sorted,
>>displayed, checked with other occurrences for uniqueness, etc.,
>>then the ID of the occurrence should be reified as a topic and
>>operated upon as any other topic. "Conveniences" in many instances
>>do not add convenience for all applications, only some subset. For
>>those other subsets, support for those "conveniences" amounts to
>>making applications quite a bit more complicated.
>>
>>I for one do NOT want Topic Maps made any more complicated. We're
>>having a hard enough sell as it is without adding more complexity
>>and altering the language any more than is *absolutely* necessary,
>>certainly not for convenience' sake.
> 
> 
> Murray , let me say it again:
> Variants are complicated because their design is very purely thought
> through.
> If it is feasible I would
> 1) Remove <variantName> wrapper:
> neither <occurrence> nor <baseName> or association <member> have any
> wrappers for terminal elements and locators.

The <variantName> is necessary in order to provide the semantics for
its child element, which without <variantName> is simply a resource
or resource reference. This says that the <resourceRef> or
<resourceData> *is* a variant name. That's unambiguous, and to all
I know of markup, being explicit is considered good markup design.

In the case of <occurrence>, the <resourceRef> or <resourceData>
*is* the occurrence, whereas in <variant> the <resourceRef> or
<resourceData> is not the variant, but its name. Same thing
with <member>: the <resourceRef> or <resourceData> *is* association
member. Semantically this seems correct.

> 2) Remove syntactic sugar of <variant> nesting.
> 
> In other words this:
> <baseName>
>   <baseNameString>ABC<baseNameString>
>   <variant>
>     <parameters>
>       <topicRef xlink:href="#p1"/>
>     </parameters>
>     <variantName>
>       <resourceRef xlink:href="a1.gif"/>
>     </variantName>
>     <variant>
>       <parameters>
>         <topicRef xlink:href="#p2"/>
>       </parameters>
>       <variantName>
>         <resourceRef xlink:href="a2.gif"/>
>       </variantName>
>     </variant>
>   </variant>
> <baseName>
> 
> Would become:
> <baseName>
>   <baseNameString>ABC<baseNameString>
>   <variant>
>     <parameters>
>       <topicRef xlink:href="#p1"/>
>     </parameters>
>     <resourceRef xlink:href="a1.gif"/>
>   </variant>
>   <variant>
>     <parameters>
>       <topicRef xlink:href="#p1"/>
>       <topicRef xlink:href="#p2"/>
>     </parameters>
>     <resourceRef xlink:href="a2.gif"/>
>   </variant>
> <baseName>

I'm not sure what the point is here. The reason we have <variantName>
is to make explicit what the reference is used for, since we have
three reference elements that are reused in various places. We could
have gotten rid of reference elements entirely and used attribute
values too. That would have obscured important functionality within
an attribute value rather than having linking elements, which are
easy to understand and easy to teach about.

I've heard the phrase "syntactic sugar" used as a pejorative for
any markup deemed by someone unnecessary or simply a convenience.
In this case, there is no sugar, only the addition of making
explicit what the reference is for.

There are many styles of approaching this specific set of markup
requirements -- we chose in the end one style. It's not the least
verbose. It is very explicit, and very simple, and doesn't hide
functionality within attributes, which I think is important. If
there's a link, there's a linking element. We could have had a
lot of linking elements; instead we have three, by the semantics
of the link not its context. The context is always provided by
the link's parent. That's simple, not sugar.

> 3)
> And the last thing ... may be rename <parameters> into <scope>
> although they are assumed to carry different semantics...

The reason we chose to rename <scope> to <parameters> in this
case was exactly because it didn't have the same semantics. It's
*not* a scope in the Topic Map sense, it's the parameters applied
to the variant. Renaming it to scope would be confusing and
incorrect, and I simply don't understand what the point would
be. This kind of change doesn't improve the language, makes it
less explicit, and is unnecessary -- meaning that (unless I'm
mistaken) it shouldn't be considered as a change to 1.0.

Again, I still don't understand the desire to muck with things
here. The stability of XTM 1.0 is a stronger need than any of
these proposed changes. You can *always* take any language and
continue to modify it, ad nauseum, for years. I don't see any
of these proposals as such an improvement that they should be
deemed *necessary*, which should still be considered the requirement
for any of them to be seriously considered. Incremental, minor
*improvements* to an interchange format are not improvements
at all if they diminish its overall acceptability. If the
underlying model changes, then the syntax should change, and
then the version number bumps up to 2.0. Otherwise, bug fixes
only. I don't see any of these as bugs.

Murray

......................................................................
Murray Altheim                  <http://kmi.open.ac.uk/people/murray/>
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK

     "In Las Vegas Mr Gates also demonstrated a prototype
      fridge magnet which can be programmed to receive traffic
      reports, sports results and advertisements from local
      restaurants using the same FM signal as the wristwatch."
                                  -- The Guardian, 10 Jan 2003.