[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Code Lists Redux
To LCSC from FPSC: In the last two weeks there has been some discussion and analysis of the code list schema fragments contributed by Lisa and commented on by Chee-Kai. During our last FPSC meeting, the tentative "example" nature of these enumerations came into question. Lisa's work at producing examples of code list schema fragments are, we gather, just that: examples for groups who maintain the information behind the enumeration to use in their long-term maintenance of the code lists. That is, that UBL wouldn't maintain the code lists, but rather the organization in charge of the information would. In FPSC we now realize that the documentary components of the example schemas are, truly, normative and not just simple documentation if we are to use them in the translation of coded values into display values, or in the translation of input values into coded values. Chee-Kai proposed changes to address the components of the information along the lines of: At 2003-07-11 19:59 +0800, Chin Chee-Kai wrote: http://lists.oasis-open.org/archives/ubl-fpsc/200307/msg00025.html >(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? Perhaps, in light of the normative nature of application information being captured in the structure: <xs:enumeration value="USD"> <xsd:annotation> <xsd:appinfo> <ccts:Presentation> <fpsc:string>US Dollar</fpsc:string> <fpsc:symbol>$</fpsc:string> </ccts:Presentation> </xsd:appinfo> </xsd:annotation> </xs:enumeration> But, this doesn't address the issue of who is going to maintain the information in the long run if FPSC requires in a formatting specification that a particular code list is to be used. Are there any thoughts of introducing normative code list XSD files in the LCSC collection of files? Thanks! ..................... 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/m/ 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/m/bc
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]