Thoughts on comment feedback from PRD01

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

Fellow CLRTC members,

Having reviewed Viswanath's input at:

  http://lists.oasis-open.org/archives/codelist-comment/200912/msg00002.html

... these are my thoughts.

(1) - I can accept renaming the document element 
<ValueListConstraints> to <ContextValueAssociation> as the current 
name reflects a more limited scope that was true when the vocabulary 
was first developed

(2) - based on my experience back with SGML and now with XML I am 
uncomfortable having enumerated sibling elements of different types 
under a common parent
     - I think encapsulating the repeating tests under a parent, and 
the repeating lists under a parent follows an accepted approach in 
vocabulary design
     - for example, when dealing with the sibling-axis in an 
XPath-based environment, it is easier when a zero-or-more-siblings 
being processed for a parent are the only items allowed under that parent

(3) - I am uncomfortable with "rule-sets-for-instance-information" as 
I don't see these as rules, but as declarations of relationships 
("rules" to me implies an imperative action of some kind)

(4) - I am uncomfortable with "instance-information" because 
"information" is too general and subject to misinterpretation

(5) - I am uncomfortable with rule-set-id="" because using xml:id= is 
recognized by modern XML languages as having XML ID semantics per the 
W3C specification:

   http://www.w3.org/TR/xml-id/

... and any other name will require additional work by users using, 
for example, XSLT 2, to process a CVA file

(6) - the element <genericode-code-identification expression="xpath"> 
builds in an assumption about the genericode addressing needed by the 
user when associating genericode list-level metadata with 
instance-level metadata ... <Version> is but one example of 
list-level metadata ... CVA users need the flexibility to use XPath 
to address *any* component of list-level metadata ... note this 
example from annex C of the CVA spec (especially note the need to use 
predicates to qualify precisely which piece of list-level metadata is 
being matched):

     <InstanceMetadataSet xml:id="cctsV2.01-code">
       <InstanceMetadata address="@listName"
                         identification="LongName[not(@Identifier='listID')]"/>
       <InstanceMetadata address="@listID"
                         identification="LongName[@Identifier='listID']"/>
       <InstanceMetadata address="@listVersionID"
                         identification="Version"/>
       <InstanceMetadata address="@listSchemeURI"
                         identification="CanonicalUri"/>
       <InstanceMetadata address="@listURI"
                         identification="LocationUri"/>
       <InstanceMetadata address="@listAgencyName"
                         identification="Agency/LongName"/>
       <InstanceMetadata address="@listAgencyID"
                         identification="Agency/Identifier"/>
     </InstanceMetadataSet>

(7) - I disagree that "binding" is a more appropriate and 
self-explanatory element name instead of "context" because this 
portion of a CVA file is listing a number of document contexts ... 
yes, I can see that the declarations are binding document contexts to 
value tests and lists and metadata, but I am concerned that "binding" 
might be an overloaded term

(8) - I am uncomfortable with instances-satisfying="" because the 
XPath address is the address of a single document context inside of 
an instance, and the fact that it exists doesn't "satisfy" anything, 
it only engages the testing of the value found at that context


In summary, I find from this contribution that changing the document 
element name could very well help the user, so I support that change 
in the next PRD.  My assessment is that the other changes may not be 
improvements from a user's perspective.

But I am biased because I am so close to the vocabulary.  What 
opinions do other members have?

I do appreciate that Viswanath has taken from his time to consider 
the public review draft and for his detailed submission with 
examples.  I thank him for this opportunity to discuss these suggestions.

. . . . . . . . . . . . Ken

--
UBL and Code List training:      Copenhagen, Denmark 2010-02-08/10
XSLT/XQuery/XPath training after http://XMLPrague.cz 2010-03-15/19
XSLT/XQuery/XPath training:   San Carlos, California 2010-04-26/30
Vote for your XML training:   http://www.CraneSoftwrights.com/o/i/
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
Video overview:  http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal