[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]