RE: [xml-dev] 3 approaches to structure lists, plus an analysisof each a

["Cox, Bruce" <Bruce.Cox@USPTO.GOV>]

Ken, does the approach you describe below address version control?
There is the unfortunate potential for country codes, for example, to be
used differently at different times, as geopolitical boundaries change.
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.


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.  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.

Bruce B Cox
Manager, Standards Development Division
USPTO/OCIO/SDMG
571-272-9004


-----Original Message-----
From: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com] 
Sent: Sunday, February 15, 2009 9:17 AM
To: 'xml-dev@lists.xml.org'
Subject: RE: [xml-dev] 3 approaches to structure lists, plus an analysis
of each approach

At 2009-02-15 07:58 -0500, Costello, Roger L. wrote:
>Thanks Ken, this is excellent. It will take me a while to absorb all 
>this, but from a brief examination of your material I conclude that 
>you recommend approach #3 - express a list as an XML instance 
>document, using domain-specific terminology (i.e. do not express 
>lists using a schema language). Is that what you recommend?

Forgive me for not having gone into more detail in direct response to 
your post, but it was dinner time on Valentine's Day that you sent 
out your initial question.  I could only make the time to do a quick 
overview of our CLRTC work.

But, no, I was not endorsing your #3, I was proposing a #4, and I had 
meant to introduce my post saying "But there is another way..." and I 
go too mired in the details.

Tony Coates's revelation in his work with business documents was not 
to use a schema (your #1 or #2), or a domain-specific XML vocabulary 
(your #3), but rather an internationally standardized cross-domain 
XML vocabulary he dubbed "genericode".  The OASIS Universal Business 
Language (UBL) project adopted genericode and it was deployed using 
Schematron and XSLT in a way that was observed to be independent of 
UBL.  I founded the OASIS Code List Representation Technical 
Committee (CLRTC) to manage the standardization of Tony's work as 
OASIS Genericode 1.0, and we are working on standardizing 
Context/value Association files, which can be used for more than your 
three scenarios of application pick lists, managed information and
validation.

Controlled vocabularies need to be managed as their own 
entities.  Genericode, as with most XML vocabularies, is targeted as 
an interchange vocabulary.  Custodians of controlled vocabularies can 
use whatever technology they want to maintain or implement their 
responsibility, genericode can be used to publish a snapshot of the 
work as assign list-level meta data to identify that snapshot.

At least two tools are available today to read and write genericode
files:

   Unimaze ebMapper - http://www.unimaze.com/ebmapper.aspx
   Crane's gc2ods   - http://www.CraneSoftwrights.com/sales/Crane-gc2ods

... and I have some free stylesheets for rendering genericode files 
in HTML for the review by people who are afraid of angle brackets (as 
I find in ecommerce circles):

   http://www.CraneSoftwrights.com/resources/ubl/index.htm#codess

... and by having a standardized format then users can choose to 
represent any controlled vocabulary with any associated value-level 
meta data, and not have to write custom tools.  The CLRTC is hoping 
many vendors will adopt genericode and CVA support in their products.

In international commerce, many code lists are maintained by 
international registrars and are published for worldwide use (country 
lists, currency lists, payment means, etc.)  I use payment means in a 
lot of my examples because it makes sense that someone, somewhere, 
would have come up with an international standardized controlled 
vocabulary for representing how to spend money:

http://docs.oasis-open.org/ubl/os-UBL-2.0-update/cl/gc/default/PaymentMe
ansCode-.0.gc

In UBL all of the information items are globally defined per the 
naming and design rules.  Trading partners may need to use different 
code lists for the same element found in different document 
contexts.  The use of context/value association files allows UBL to 
specify which code lists are used where in the document, a 
customization community to layer on top of that their constraints for 
code lists, and then for trading partners to layer on top of that 
specific constraints for code lists between two parties.  All without 
touching the UBL schemas, which is important when claiming 
conformance.  And in the course of business, code list constraints 
between trading partners change all the time, and this approach means 
you don't have to change the schemas.

BTW, in the same way that CALS tables were a generic markup 
vocabulary for the expression of dense tabular structures, genericode 
can be used as a generic markup vocabulary for keyed sparse tabular 
structures.  An application of this is the association of document 
model information in UBL keyed on unique ISO/IEC 11179 Dictionary 
Entry Names maintained in spreadsheets.  I published all the UBL 
International Data Dictionary (IDD) spreadsheets as genericode files 
so that programmers can work with the IDD without having to read the 
spreadsheets:

 
http://www.CraneSoftwrights.com/resources/ubl/index.htm#ubl2idd2generico
de

... in turn these were used in the creation of a multi-lingual user 
interface in an OpenOffice 3 tool that specifies customization subsets
of UBL:

   http://www.CraneSoftwrights.com/sales/Crane-UBLProfile/#doctype

Anyone in Europe interested in this can attend my delivery in March 
2009 in Brussels of our one-day hands-on "Practical Code List 
Implementation (Using Controlled Vocabularies in XML Documents)":

   http://www.CraneSoftwrights.com/schedule.htm#pcli
   http://www.CraneSoftwrights.com/training/pcli/pclisyl.htm

I'm delivering a lecture on this at XML Prague 2009
http://www.XMLPrague.cz

It is also possible I'll be delivering the class in Hong Kong in April.

I also sell a book of the training material (published last week):

   http://www.CraneSoftwrights.com/training/#pcli-dl

I hope this helps.

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

--
Upcoming hands-on XSLT, UBL & code list hands-on 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@CraneSoftwrights.com
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