[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Thursday's four approaches to instance representation of code list supplementary values
(sorry; this document is unchanged from a few minutes ago but has a better subject line for finding the document) The following is a working document circulated for analysis of options available for design work. Two requirements not present in the 2004-02-12 code list representation working draft are: (A) - that the supplementary components of the code lists of code list values utilized in a UBL instance be available in the XML instance proper without any processing from any external source including any schema expression (B) - that the supplementary components be available for all code-list-value information items even when two or more such information items are found in the set of #PCDATA and attribute information items for any given element At the present time no UBL information item has more than one component information item that has a value from a code list. This document describes a possible future situation in which more than one component information item is a value from a code list. All of the methodologies accommodate a single code list value or more than one code list value. In this document the example currency code list has two supplementary components, and the example country code list has three supplementary components. In this document the data model for UBL indicates that the "amount" element has two code-list-valued attributes so the schema for the element "attribute" is declared to have two attributes named as indicated in the spreadsheet and prefixed using the code list data type prefix. For the purposes of analysis and assessment, four approaches to the capturing of code list supplementary components could be referred to as: (1) - Articulated URN (2) - Meta-data block - namespace in attribute (3) - Meta-data block - namespace in element type (4) - Namespace-qualified supplementary components These are outlined as follows: (1) - Articulated URN - the supplementary components for a given code list are in the namespace URI reserved for that code list - e.g.: xmlns:curr="urn:oasis:names:tc:ubl:CodeList:Currency:ISO:1234:2002" - e.g.: xmlns:cty="urn:oasis:names:tc:ubl:CodeList:Country:ISO:4567:1999:7" - instance fragments: <in:invoice xmlns:curr="urn:oasis:names:tc:ubl:CodeList:Currency:ISO:1234:2002" xmlns:cty="urn:oasis:names:tc:ubl:CodeList:Country:ISO:4567:1999:7" ...> ... <amount curr:currency="CAD" cty:country="CA">123</amount> (2) - Meta-data block - namespace in attribute - the supplementary components for a given code list are in a meta-data block at the start of the document - each generic entry in the block identifies the code list by its namespace URI found in an attribute - the document model for a generic entry has all attributes optional and validation is done as a separate process of co-occurrence constraint checking - instance fragments: <in:invoice xmlns:curr="---arbitrary-currency-URI-here---" xmlns:cty="---arbitrary-country-URI-here---" xmlns:in="---UBL invoice--" xmlns:cl="---UBL code list generic---" ...> <cl:meta-data-block> <cl:meta-data ns="---arbitrary-currency-URI-here---" agency="xxx" date="yyy"/> <cl:meta-data ns="---arbitrary-country-URI-here---" agency="xxx" date="yyy" version="zzz"/> </cl:meta-data-block> .... <amount curr:currency="CAD" cty:country="CA">123</amount> (3) - Meta-data block - namespace in element type - the supplementary components for a given code list are in a meta-data block at the start of the document - each specific entry in the block identifies the code list by its namespace URI found by the matching element type's namespace - the document model for a specific entry can specify required and attributes and checking can be done by a schema expression - instance fragments: <in:invoice xmlns:curr="---arbitrary-currency-URI-here---" xmlns:cty="---arbitrary-country-URI-here---" xmlns:in="---UBL invoice--" xmlns:cl="---UBL code list generic---" ...> <cl:meta-data-block> <curr:meta-data agency="xxx" date="yyy"/> <cty:meta-data agency="xxx" date="yyy" version="zzz"/> </cl:meta-data-block> .... <amount curr:currency="CAD" cty:country="CA">123</amount> (4) - Namespace-qualified supplementary components - the supplementary components for a given code list are in attributes of the element in which the information item is found - the schemas are synthesized to include as many supplementary component attributes for each code list value using the namespace of the code list - the local parts of the attribute names are standardized for all code lists - the schemas can make those that are required to be required in the syntax and validated by W3C schema - instance fragments: <in:invoice xmlns:curr="---arbitrary-currency-URI-here---" xmlns:cty="---arbitrary-country-URI-here---" xmlns:in="---UBL invoice--" xmlns:cl="---UBL code list generic---" ...> .... <amount curr:currency="CAD" curr:agency="xxx" curr:date="yyy" cty:country="CA" cty:agency="xxx" cty:date="yyy" cty:version="zzz">123</amount> Addendum - in preparing this note I found that there are already some elements in UBL that have what look like supplementary components as attributes: these would have to be checked; the following is not an exhaustive list but is a set of examples: cbc:PriceAmount cbc:PriceAmount/@codeListVersionID cbc:PriceAmount/@currencyID cbc:BaseQuantity cbc:BaseQuantity/@unitCode cbc:BaseQuantity/@unitCodeListAgencyID cbc:BaseQuantity/@unitCodeListAgencyName cbc:BaseQuantity/@unitCodeListID cbc:MaximumQuantity cbc:MaximumQuantity/@unitCode cbc:MaximumQuantity/@unitCodeListAgencyID cbc:MaximumQuantity/@unitCodeListAgencyName cbc:MaximumQuantity/@unitCodeListID cbc:MinimumQuantity cbc:MinimumQuantity/@unitCode cbc:MinimumQuantity/@unitCodeListAgencyID cbc:MinimumQuantity/@unitCodeListAgencyName cbc:MinimumQuantity/@unitCodeListID cbc:MaximumAmount cbc:MaximumAmount/@codeListVersionID cbc:MaximumAmount/@currencyID cbc:MinimumAmount cbc:MinimumAmount/@codeListVersionID cbc:MinimumAmount/@currencyID -- US XSL training: Washington,DC March 15; San Francisco,CA March 22 World-wide on-site corporate, government & user group XML training 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) Male Breast Cancer Awareness http://www.CraneSoftwrights.com/o/bc To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ubl/members/leave_workgroup.php. -- US XSL training: Washington,DC March 15; San Francisco,CA March 22 World-wide on-site corporate, government & user group XML training 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) Male Breast Cancer Awareness http://www.CraneSoftwrights.com/o/bc
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]