[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fwd: Re: [codelist] Thoughts on comment feedback from PRD01
>Subject: Re: [codelist] Thoughts on comment feedback from PRD01
>To: "G. Ken Holman" <gkholman@cranesoftwrights.com>
>Date: Mon, 18 Jan 2010 14:31:55 -0000
>From: "Anthony B. Coates (Londata)" <abcoates@londata.com>
>
>I can't attend the telecon today; this is just to say that I have no
>problems with Ken's proposal's below, so you can add me as an "aye".
>
>Cheers, Tony.
>
>On Mon, 11 Jan 2010 17:57:22 -0000, G. Ken Holman
><gkholman@cranesoftwrights.com> wrote:
>
>>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
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe from this mail list, you must leave the OASIS TC that
>>generates this mail. Follow this link to all your TCs in OASIS at:
>>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>--
>Anthony B. Coates
>Associate Director
>Document Engineering Services (Limited)
>UK: +44 (20) 8816 7700, US: +1 (239) 344 7700
>Mobile/Cell: +44 (79) 0543 9026
>Skype: abcoates
>anthony.coates@documentengineeringservices.com
>http://www.documentengineeringservices.com/
--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]