Re: [ubl-fpsc] Code lists as a repository of code list supplemental information

[Chin Chee-Kai <cheekai@softml.net>]

>>> >><xs:enumeration value="USD">
>>> >>      <xs:annotation>
>>> >>              <xs:documentation>
>>> >>                      <xhtml:div class="Code_List._Expansion._String">
>>> >>                              <xhtml:p>US Dollar</xhtml:p>
>>> >>                      </xhtml:div>
>>> >>                      <xhtml:div class="Code_List._Expansion._Symbol">
>>> >>                              <xhtml:p>$</xhtml:p>
>>> >>                      </xhtml:div>
>>> >>              </xs:documentation>
>>> >>      </xs:annotation>
>>> >></xs:enumeration>
>>
>>The latter ... that any product or technology might read the XSD
>>expressions and distill the two transliterations:
>>
>>   "USD" -> "US Dollar"
>>   "USD" -> "$"
>>
>>.. and I suppose for input and validation purposes:
>>
>>   "US Dollar" -> "USD"

In that case, I thought of the following:

(1).  xhtml wouldn't be the "right" way to store them as
      XHTML is intended for presentational data, less so
      for informational data.

(2).  In LC, we're converting the previous attribute-based
      schema metadata to element-based storage, in the 
      standardized form of :
	<xsd:annotation>
	  <xsd:documentation>
	    <ccts:Component>
	      <ccts:CategoryCode>ABIE</ccts:CategoryCode>
	      <ccts:ObjectClass>Address</ccts:ObjectClass>
	      ...
	    </ccts:Component>
	  </xsd:documentation>
	</xsd:annotation>

      Might FP consider proposing useful element structure
      to store as part of the ccts space?  I'm imagining
      something like:
	<xsd:annotation>
	  <xsd:documentation>
	    <ccts:Component>
	      ...
	    </ccts:Component>
	    <ccts:Presentation>
	      <!-- FPSC proposed structure -->
	    </ccts:Presentation>
	  </xsd:documentation>
	</xsd:annotation>


      If we use this structure, I think it'll standardize
      storage of all the various aspects of metadata 
      pertaining to the schema.

      Would this be more appropriate?




(3).  And this one's for you, Lisa.

      Given that Ken's use of the data is for processing
      purposes rather than to provide in-line documentation,
      and that we could hardly expect not to have metadata
      meant for machines when XML's advantage is that it
      is machine processable,  I was wondering why there
      was an earlier decision by NDR to rule out categorically
      any use of <xsd:appinfo>.  

      I also find those <ccts:Component> metadata appears
      more appropriate for processing purposes than as
      documentation of the schema, since many downstream
      tranformations could rely on the ObjectClass,
      RepresentationTerm etc properties to drive their
      transformation behaviors.

      I'd be happier if we use <xsd:appinfo> than
      <xsd:annotation> for such machine-oriented purposes.

      Another battle-front for NDR?




Best Regards,
Chin Chee-Kai
SoftML
Tel: +65-6820-2979
Fax: +65-6743-7875
Email: cheekai@SoftML.Net
http://SoftML.Net/