[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: 3 approaches to structure lists, plus an analysis of each
At 2009-02-18 19:47 -0500, Cox, Bruce wrote: >Ken, does the approach you describe below address version control? Absolutely. Each version of every list has unique list-level meta data in the XML genericode file expressing the values of the list. >There is the unfortunate potential for country codes, for example, to be >used differently at different times, as geopolitical boundaries change. Indeed. Each code in every list can have value-level meta data expressed in the genericode file, helping the reader understand the semantics represented by each code. >For a patent publication, we feel we need to know when the country code >in question was in force, so the version of the list used is important. It is important to cite *in the XML document* the instance-level meta data identifying the list-level meta data of the list from which the value in the instance was obtained. This gives the recipient the value-level meta data to interpret the intended semantics of the value. For example, the UN/CEFACT Core Component Technical Specification (CCTS) 2.01 core component types define a number of facets of instance-level meta data, called "supplementary components", that are attributes attached to the element that contains the code as content or the code as an attribute. The XML instance author can choose to leave the instance-level meta data empty, in which case the interpretation of the code is up to the receiver ... for example, a currency value of "USD" is probably US dollars. But in your example omitting instance-level meta data might make interpretation ambiguous and imprecise. Specifying instance-level meta data with the country code one would convey the unambiguous values of list-level meta data of the code list from which the code was derived, thus leading the recipient of the code to inspect the value-level meta data associated with the code to comprehend the semantics represented by the value used. >Our situation is complicated by the fact that there are Offices issuing >patent rights that are not associated with a country, but cover a larger >region, such as the European Patent Office. Not a problem with the use of context/value association files declaring that the values of a particular XML information item are governed by the union of two genericode lists: one for the ISO country codes (and their semantics for the values), and one for the patent community's representation of regions (perhaps that's another list). >These institutions are >given two-letter codes in WIPO Standard ST.3, which also incorporates >ISO codes for all the member states' Offices. Yes, it duplicates ISO >country codes, but only because the UN does not always recognize the >changes in political boundaries *at the same time* that the ISO >standards are updated, so WIPO has to have its own "politically correct" >list. Oh, then I suppose you wouldn't accept the ISO semantics for the values, so you don't need that union. You could simply point to the single WIPO country code list, citing a particular version of that list. But this underscores the importance of the instance-level meta data to tell the recipient how to interpret a particular coded value ... to expand on an example from my book you might have: <PatentFilingCountry listSchemeURI="urn:x-WIPO:Country Codes:1992" >CS</PatentFilingCountry> ... representing Czechoslovakia, and <PatentFilingCountry listSchemeURI="urn:x-WIPO:Country Codes:2007" >CS</PatentFilingCountry> ... representing Serbia and Montenegro. Without the instance-level meta data, just having the value "CS" would be ambiguous. So you want *both* lists (or as many lists) to apply to the same element content, and this can be expressed in context/value association as the union of two (or more) versions of the WIPO list. With the appropriate genericode files the free Schematron implementation of CVA validation on our web site would successfully validate: <PatentFilingCountry listSchemeUri="urn:x-WIPO:Country Codes:1992" >FI</PatentFilingCountry> ... and: <PatentFilingCountry listSchemeURI="urn:x-WIPO:Country Codes:1996" >SF</PatentFilingCountry> ... while rejecting: <PatentFilingCountry listSchemeURI="urn:x-WIPO:Country Codes:1996" >FI</PatentFilingCountry> ... thus allowing only the single entry for Finland in each of two lists with two different values based on the list versions. There are strategies for omitting instance-level meta data should you anticipate a value to be added to a list, say, six months from now: create your instance without instance-level meta data, and validate with the union of the published list and your custom extension list with the future value. Later on when the new list is published, the instance doesn't change but it will validate with the new list, not unioned with your temporary transition extension that has since evaporated. But there is a risk that the committee ends up using a different value and the instance won't validate ... but at least there was a migration strategy when the future information was more certain. When designing your XML vocabulary for the use of code lists and identifiers, you have a responsibility to provide for instance-level meta data. With a few minor exceptions, the UN/CEFACT supplementary components for codes are expressed in the attributes: listID= listAgencyID= listAgencyName= listName= listVersionID= listURI= listSchemeURI= The UN/CEFACT supplementary components for identifiers are expressed in the attributes: schemeAgencyID= schemeAgencyName= schemeName= schemeVersionID= schemeDataURI= schemeURI= For those archive readers with a copy of our "Practical Code List Implementation", this is detailed for UN/CEFACT core component types on pages 48/49. I'll be talking more about these concepts at XML Prague 2009 http://www.xmlprague.cz trying to convey the importance to designers of XML vocabularies. I hope this helps, Bruce. . . . . . . . . . Ken -- Upcoming hands-on XQuery, XSLT, UBL & code list training classes: Brussels, BE 2009-03; Prague, CZ 2009-03, http://www.xmlprague.cz Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video Video lesson: http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18 Video overview: http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18 G. Ken Holman mailto:gkholman@C... Crane Softwrights Ltd. http://www.CraneSoftwrights.com/x/ Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/x/bc Legal business disclaimers: http://www.CraneSoftwrights.com/legal
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|