[xtm-wg] My Vote on AG Review Specification

[Murray Altheim <altheim@eng.sun.com>]

I vote "NO WITH REASONS" on the current AG Review draft of XTM 1.0.
These reasons include my difficulties with the process under which the
specification was created, as not being in keeping with the mandate
given the editors in Paris. I have enumerated these issues in detail
in previous messages and believe it unproductive to reopen issues 
that were raised and then never discussed openly.

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.

Among my difficulties with the process included unwarranted and what
I consider unauthorized alterations to the XTM 1.0 DTD. The editors
were given wide latitude in making changes to the specification as
necessary in order to publish the document, but I left Paris with the
distinct understanding that DTD changes (which affect the stability 
of all of our work) were to undergo greater scrutiny, and required
more than a simple majority vote under conditions of urgency (that 
included a very shortened deadline). Three of the four changes made
to the DTD had no vote whatsoever. I do not consider these "bug fixes."

These changes I believe are detrimental to XTM, in terms of the
an accurate implementation of the model, the interpretation of XTM 
topic maps, the perceived stability of our work, and the notion of
consensus (or at least some realistic measure of agreement), including
proper and open process. I also believe they represent new bugs in our
design, and include:

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.

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.

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.

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

I believe we were much better off with the XTM DTD we agreed upon during
the Paris meeting (v1.17), and I see little reason to wish to alter the
one chosen by the group to the version delivered by the editors. The v1.17 
DTD represented a bug fix on a "Release" version of the DTD made public 
in Washington and had been agreed upon by the group. I don't believe we've
seen a proper discussion or vote on the DTD changes made one day prior to
publication of the AG Review Specification that would authorize these 
changes. 

Murray

...........................................................................
Murray Altheim, SGML/XML Grease Monkey     <mailto:altheim&#64;eng.sun.com>
XML Technology Center
Sun Microsystems, 1601 Willow Rd., MS UMPK17-102, Menlo Park, CA 94025

      In the evening
      The rice leaves in the garden
      Rustle in the autumn wind
      That blows through my reed hut.  -- Minamoto no Tsunenobu

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

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

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