OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-fpsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


At 2003-07-11 19:59 +0800, Chin Chee-Kai wrote:
> >>> >><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.

Okay ... though we are dealing with presentational information.  I can read 
it both ways and would welcome changing it in order to treat these two 
translations as first-class information.

I had assumed that since this was the only information associated with the 
enumerated values that it was desired to encode it as documentary 
constructs.  But, with you asking the question, I acknowledge that the 
documentary constructs are second-class and we in FPSC need the information 
to be first-class in order to both rely on the information and make it 
normative in the UBL code list usage.

>(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?

It looks good to me, but just being a stylesheet geek I'm unfamiliar with 
the rules and constraints of ccts and how they are to be utilized.

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

W3C Schema http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ section 
3.13.2 distinguishes application information in <xsd:appinfo> from user 
documentation in <xsd:documentation> ... *both* of which are in 
<xsd:annotation>.

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

--
Upcoming hands-on courses: in-house corporate training available;
North America public:  XSL-FO Aug 4,2003; XSLT/XPath Aug 12, 2003

G. Ken Holman                mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.         http://www.CraneSoftwrights.com/o/
Box 266, Kars, Ontario CANADA K0A-2E0   +1(613)489-0999 (F:-0995)
ISBN 0-13-065196-6                      Definitive XSLT and XPath
ISBN 0-13-140374-5                              Definitive XSL-FO
ISBN 1-894049-08-X  Practical Transformation Using XSLT and XPath
ISBN 1-894049-11-X              Practical Formatting Using XSL-FO
Member of the XML Guild of Practitioners:    http://XMLGuild.info
Male Breast Cancer Awareness http://www.CraneSoftwrights.com/o/bc



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]