OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

clr-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [clr-dev] Additional information about InstanceMetadataSets


Hi Ken,

I don't see anything in the CVA format that would inform what a 
preferred code list would be, when there is a metadata in scope. A human 
mind would guess the newest codes (e.g. iso3166-2010.gc) would be the 
ones to use for new documents, but... what about computers? Or maybe 
it's not part of the CVA philosophy to care...

Eric.

On 10/7/2010 8:22 PM, G. Ken Holman wrote:
> Hi Eric!  I see from Juerg's post that you posted today but for some
> reason a copy never made it to my inbox. I'm pleased to take a moment to
> explain instance metadata sets. I believe you understand the basics, but
> please allow me to explain the whole situation for readers of the
> archive who have not progressed to the point where you are.
>
> While some code lists can live in isolation (thus not needing instance
> metadata for disambiguation; say directions of latitude and directions
> of longitude for two examples), I think it is wise to model metadata for
> *all* code lists in an XML vocabulary.
>
> Consider a country code from the most current UN/CEFACT list of ISO 3166
> country codes:
>
> http://www.unece.org/cefact/recommendations/country.htm
>
> ... in particular key 189 SERBIA & MONTENEGRO has the country code "CS".
>
> Before 1993, the ISO country code "CS" represented Czechoslovakia. In
> 2006 there was no "CS" code in the ISO country list (I chose that year
> because I use that list in another project).
>
> So, if you see a document with the following:
>
> <country>CS</country>
>
> ... is it ambiguous? Do you rely on the date of the document? Not if it
> is a document documenting historical information.
>
> To disambiguate the ISO country code, thus indicating exactly the
> semantics represented by the coded value, one could add, say, a metadata
> attribute of the year in which the list was published. Thus this would
> be the coded value for Czechoslovakia in your XML data instance:
>
> <country isoyear="1990">CS</country>
>
> ... whereas this would be the coded value for Serbia and Montenegro:
>
> <country isoyear="2010">CS</country>
>
> ... and this would be in error because *no* country had that code in 2006:
>
> <country isoyear="2006">CS</country>
>
> Without the metadata you don't know which country you are referencing
> unless you have prior agreement with your trading partner that, say, all
> codes are post 2010. But who knows if ISO will five years from now
> retires another code and reassigns it? So it is safest to code it with
> the metadata to indicate which code list is being used.
>
> Assuming you have a genericode file for each year:
>
> iso3166-1990.gc - with <Version>1990</Version> in <Identification>
> iso3166-2006.gc - with <Version>2006</Version> in <Identification>
> iso3166-2010.gc - with <Version>2010</Version> in <Identification>
>
> ... and a declaration in the CVA file for each:
>
> <ValueList xml:id="country1990" uri="iso3166-1990.gc"/>
> <ValueList xml:id="country2006" uri="iso3166-2006.gc"/>
> <ValueList xml:id="country2010" uri="iso3166-2010.gc"/>
>
> ... and you have a document context in the CVA file describing your
> country element that points to the item in your XML using address="":
>
> <Context address="country" values="country1990 country2006 country2010" ...
>
> ... you have to describe in the CVA file where the genericode <Version>
> element information is found relative to the <country> element in your
> XML. It is found in the isoyear="" attribute. So in your context you
> point to a metadata set:
>
> <Context address="country" values="country1990 country2006 country2010"
> metadata="iso3166metadata"/>
>
> ... and in the metadata set in the CVA file you associate the address of
> the isoyear="" attribute of your XML (relative to the context item) with
> the address of the <Version> element of your genericode (relative to
> <Identification>):
>
> <InstanceMetadataSet xml:id="iso3166metadata">
> <InstanceMetadata address="attribute::isoyear"
> identification="child::Version"/>
> </InstanceMetadataSet>
>
> ... or more succinctly as:
>
> <InstanceMetadataSet xml:id="iso3166metadata">
> <InstanceMetadata address="@isoyear" identification="Version"/>
> </InstanceMetadataSet>
>
> Now the validation will use only the 1990 genericode file when
> isoyear="1990", only the 2006 genericode file when isoyear="2006" and
> only the 2010 genericode file when isoyear="2010". It will use all three
> files in the absence of the isoyear="" attribute. It will use none of
> the files if the isoyear="" attribute is a value other than "1990",
> "2006" or "2010".
>
> If one uses the free CVA to XSLT conversion package found here:
>
> http://www.CraneSoftwrights.com/resources/ubl/index.htm#codelist
>
> ... and creates the XSLT for validating the above three lists, then this
> will validate (because it is ambiguous):
>
> <country>CS</country>
>
> ... these two will validate (because the codes exist in the respective
> lists):
>
> <country isoyear="1990">CS</country>
> <country isoyear="2010">CS</country>
>
> ... and this will be flagged in error (because the code does not exist
> in the respective list):
>
> <country isoyear="2006">CS</country>
>
> To summarize, the instance metadata is used to associate metadata
> attributes of your XML with metadata values in the identification
> section of genericode files.
>
> With the above explanation, can you suggest where to improve the
> documentation?
>
> I hope this example helps.
>
> . . . . . . . . . . . Ken




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]