[sc34wg3] Use cases for occurrence variants

[Lars Marius Garshol]

* Murray Altheim
| 
| 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.

I don't think there's any question that Nikita is right, Murray.
Taking out <variantName> does not lose any information. Those reading
the XML can still know what the <resource*/> element represents.
 
| In the case of <occurrence>, the <resourceRef> or <resourceData>
| *is* the occurrence, [...]

Actually, not any more. We changed the definition of occurrence in the
SAM. 

| [...] whereas in <variant> the <resourceRef> or <resourceData> is
| not the variant, but its name.

XTM defines those two terms to be the same. In either case, what the
markup represents is defined by the specification, not by the element
type names. In HTML, <p> elements do not delimit "p"s, but
"paragraph"s.

| Same thing with <member>: the <resourceRef> or <resourceData> *is*
| association member.

You mean <topicRef/> & <subjectIndicatorRef/> rather than
<resourceData>, I guess (and "refers to", rather than "is").

* Nikita Ogievetsky
|
| 2) Remove syntactic sugar of <variant> nesting.
 
* Murray Altheim
|
| I'm not sure what the point is here. 

The point is simplification of the markup.

Note that I agree with most of what you say about the design of XTM,
and though verbose I agree it's an unusually clean design. There are
some little warts here and there, but overall I like it, and I think
most people in the community agree with that. (At least I've never
heard anyone even hint that we should redesign it.)
 
* Nikita Ogievetsky
|
| 3)
| And the last thing ... may be rename <parameters> into <scope>
| although they are assumed to carry different semantics...
 
* Murray Altheim
|
| 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. 

That's what the SAM does, and I don't see what, besides a special case
of scope, this could possibly by. It specifies the contexts in which
the variants are appropriate. Well, that's scope. It's *exactly* the
same as scope on display and sort names in HyTM.

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

Well, either SAM is right and XTM wrong, or the other way around.
 
| 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.

Now this is an argument I have sympathy for. It would be useful to
hear what other people think as well. What is more important: minor
improvements to XTM, or stability?

| If the underlying model changes, then the syntax should change, and
| then the version number bumps up to 2.0.

Well, the trouble is that the underlying model *has* changed, but only
very slightly. Personally, I have a lot of sympathy for the "lets make
all the changes in a single jump"-view.

| I don't see any of these as bugs.

I would tend to agree. Warts, yes. Bugs, no.

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >