[sc34wg3] Use cases for occurrence variants

[Nikita Ogievetsky]

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.

> 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.
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>

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

--Nikita.