Re: [xtm-wg] My Vote on AG Review Specification

[Steve Pepper <pepper@ontopia.net>]

At 14:03 15/02/01 -0800, Murray Altheim wrote:
>I vote "NO WITH REASONS" on the current AG Review draft of XTM 1.0.
>...
>I sent the technical contents of this message to the editors last 
>Sunday privately in hopes of understanding their justifications for 
>these changes, but have heard no reply. Absent any dialogue hence I 
>send in my vote accordingly.

I apologize for the delay in replying. One reason is that I've been
having a lot of trouble with email recently. However, I did also
intend that this week (from Feb 10 to Feb 17) be devoted to questions
arising from the the *editors' resolution of comments* submitted
during the period Feb 3 to Feb 10. Murray's arguments for why he
opposed the DTD changes arrived *after* the spec went out for
balloting and could therefore not have been taken into account.

We did briefly explain all the DTD changes 2 or 3 weeks ago in
response to a request from Sam. In the absence of further discussion
we saw no need for further explanations, especially since *none of
the changes broke backwards compatibility*. However, I will give a
brief response to Murray's comments, since his is the only NO vote
that I have seen.

>1. made variantName optional in variant
>
>    Why? This IMO misunderstands the idea behind the <variant> element. 
>    During processing a particular <variant> is chosen according to
>    a particular combination of <parameter>s. At any point during
>    traversal of this tree (say, with parameters for "icon", "color"), 
>    the <variantName> at that level is always an appropriate substitute 
>    for that base name's <baseNameString>. If while traversing the 
>    <variant> tree the next subtree of options fails to find a match 
>    (say, after "icon" and "color" there fails to be a "64x64px" option), 
>    the processor can still use that level's <variantName>. By making 
>    <variantName> optional, you've created subtrees that may have no 
>    <variantName>, so that the processor is not guaranteed a suitable 
>    resource should it make a selection based on a given set of 
>    <parameter>s.
>
>    The entire <variant>/<variantName> structure mirrors the <baseName>/
>    <baseNameString> structure, where <parameter> is isomorphic with 
>    <scope>, simply renamed. During the design phase it was originally 
>    named <scope>, but this was felt to be too confusing, and not 
>    appropriate to the machine processing aspect of the concept. We've 
>    previously seen and voted down proposals to make <baseNameString> 
>    optional; for the same reason I feel this change is in error.

The editors did actually think this was a bug *even as originally
intended*, since the examples in the AG Review Spec of Dec 4th would
otherwise be invalid. However, even if they had not been invalid,
we would have regarded it as a bug.

There were discussions in Paris about the handling of nested variants
and they are reflected in the following text of Annex F:

   The processing context of a variant name defined by a <variant>
   element is defined as the union of the parameters of the <variant>
   element and all of its ancestor <variant> elements.

   Thus a variant name with a set of parameters is equivalent to
   having the same set of parameters on a parent variant and having
   no additional parameters itself.

The consequence of this is that an XTM processor basically has to
flatten the nested structure, resolving the inheritance of parameters
in the process, before evaluating the variant names to find the one
that is most suitable. Given this, there can never be a situation
in which a processor "is not guaranteed a suitable resource", as
Murray writes.

Of course, anyone that wants to use the mechanism in the exact
manner Murray describes (and this is obviously only one among many
alternatives) is free to make sure that there is a <variantName>
inside every <variant>. We have not removed this possibility,
merely made it optional.

>2. changed ID to #IMPLIED on association
>
>    <association> elements need to be addressable resources. My understanding
>    is that <association> is a subtype of <topic>. Is this no longer so? Why
>    not? Have we altered the model to suit a new view? If one cannot reference
>    an association within a topic map, how is this change represented in the
>    graph? While the absence of a normative processing model is assuredly a
>    great difficulty for the community (which will IMO lead to non-interoper-
>    able implementations), my understanding of both the CM and the PM is that
>    failure to guarantee that both t-nodes and a-nodes (using the older
>    terminology) are addressable leaves the processor unable to access or
>    state relationships between these nodes.

Murray's understanding is incorrect. It was decided in Paris to remove
all forms of subtyping from topic. One reason for this was that the
generalized reification mechanism rendered it unnecessary, and even
potentially confusing. So associations are *not* subtypes of topics and
do not therefore need to mirror their attributes. There is therefore no
reason to require IDs on <association> elements. Again, this does
not *prevent* people from putting them there; thus this change, too,
maintains backwards compatibility.

>3. changed ID to #IMPLIED on resourceData
>
>    This is a similar argument to #2. Steve Newcomb argued forcibly prior to
>    Washington that <resourceData> is a unique case, requiring an id because
>    it represents what must be an addressable resource. Without an id, how 
>    would one actually point to the <resourceData> element contents as 
>    resources? In the graph, these resources no longer have their element 
>    tree (syntax) relationships to their parent <topic> elements, and 
>    following a merging process may be no longer discernable. Requiring an 
>    id solved this problem. I would be most interested to see an explicit 
>    response to this change from Steve Newcomb, as I don't consider his 
>    silence as agreement. If the design has changed so markedly as to no
>    longer require that <resourceData> be addressable, I'd like to 
>    understand why. We received NO information on these changes prior to
>    them simply being made at the last minute.

The current editors have never heard this argument, and it was not
raised after the release of the Final Draft on Feb 3rd, by Steve or
anyone else. We do not understand the need for special-casing
<resourceData>. To us it is much cleaner -- and much more appropriate --
that only <topic> elements are required to have IDs. Once more, there
is nothing to prevent anyone who needs their <resourceData> elements
to be addressable from giving them IDs -- we are still backwardly
compatible. On the other hand, *requiring* them would seem unnecessarily
proscriptive. (*I* have certainly been able to create and process
topic maps that had no IDs on their <resourceData> elements.)

>4. changed PLUS to REP on member
>
>    This allows someone to create an entire topic map (say, the entire
>    Cyc ontology) with all associations represented by only roles played,
>    as in a giant template. With no requirement for actual topics in
>    associations, we have templates. That this change was made despite
>    voiced opposition (in other words, with knowledge that there was
>    by no means agreement within the group) indicates that it was not
>    simply a "bug fix." 

This issue has been discussed at length by the AG on and off this
list and I won't go into all the arguments. The editors felt it
was important to avoid an unnecessary lack of consistency between the
conceptual model and the DTD. One or the other had to change, and
the change we made was the one that permitted greater freedom of
expression (namely, the ability to use topic maps to express
incomplete knowledge: "I know that X is married, but not who to").

I emphatically reject the idea that this has brought in templates
through the back door. Templates were already and have always been
possible (depending on how you wanted to do them). Allowing empty
<member> elements did not create this situation, neither was the
desire to allow templates the rationale for choosing as we did.
On the contrary: Our goal was to expunge all vestiges of templates,
in accordance with the Paris decision.

In summary: Murray's interpretation of our reasons for making
the four changes to the DTD are all mistaken in one way or
another, and we are confident that the disastrous results he
predicts will not come about. It is my hope that Murray, too,
at least hopes that he is mistaken :-)

Steve

--
Steve Pepper, Chief Technology Officer <pepper@ontopia.net>
Convenor, ISO/IEC JTC1/SC34/WG3  Editor, XTM (XML Topic Maps)
Ontopia AS, Maridalsveien 99B, N-0461 Oslo, Norway.
http://www.ontopia.net/  phone: +47-22805465  GSM: +47-90827246


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

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

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