[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ubl-ndrsc] Feedback from the XrML TC on the code list rules
I have been communicating with folks in the XrML TC about our code list recommendations. They are interested in using what we've done, but are seeking more guidance on various issues such as the responsibilities of code list agencies vs. code list users. I will be talking with them further this week. Below is one of the messages in the thread that captures pretty much all the main themes we've discussed; you probably want to read it "in reverse". I'd be grateful for feedback especially in the following areas: - What's the proper way of asking the CCTS work to include more detail on what's required in a code list version identifier? - Should we be approaching and advising agencies about how to fill in the supplementary component values for their own lists? If so, what exactly should we be advising them to do? Can we build up a few examples of legitimate sets of supplementary component values for various likely code lists? - Is there enough evidence that additional supplementary components (e.g., for code list publication/introduction date) are needed? If so, how do we submit this suggestion? - Do you agree with my recommendation to add more metadata as necessary? Thanks, Eve -------- Original Message -------- Subject: Re: [rights-specification] CR00002 Date: Fri, 30 Aug 2002 13:42:53 -0400 From: Eve L. Maler <eve.maler@sun.com> To: DeMartini, Thomas <Thomas.DeMartini@CONTENTGUARD.COM> CC: 'Krishna Sankar' <ksankar@cisco.com>, Reddy, Hari <Hari.Reddy@CONTENTGUARD.COM> ... Of course, you're absolutely right that some kind of "locking-down" is needed in order to know which meaning of a code is intended. Note that UBL layers itself on top of the ebXML Core Components, in which the Code.Type core component type has been assigned version (and other) metadata for the purpose of semantic clarity of a code. Thus, UBL just borrows the entire notion of semantic clarity from ebXML, and doesn't dictate the form of the version information -- so I can't give you an "official UBL answer" here. But I can give suggestions. What's ideal is for you to get guidance from the ISO code list owners themselves about how to refer uniquely to the desired code lists using the standard metadata. If they had supplied you with a ready-made schema for country codes, as UBL is suggesting they do, they would have indicated the expected version values, and might have provided additional metadata fields for you to use as well. (I suspect that the ebXML folks haven't gone quite far enough in specifying/advising on the proper usage of version information. I will pass along this observation. BTW, may I forward this email exchange to the ubl-comment list for their perusal as well?) In the meantime, I would suggest that you provide as much metadata as you think is necessary for clarity (including, for example, introduction dates if you think it's appropriate), and that you also try to use the canonical version field to match some approximation of a version, such as "V-5". Your usage of this field should be documented in some fashion. In other words, until you can get the code list owner to solve this problem for you, you'll need to solve it for yourself. Eve DeMartini, Thomas wrote: > Eve, ... > What follows is some idea of the history, to see where they are > coming from: > > -- > > XrML 2.0 had a simple type with an enumeration of country codes, a > snap-shot of the codes at one point in time. Concern was raised that > this made the schema too big and didn't provide any value-add and wasn't > consistent with MPEG-7 way of defining country codes. > > Thus, XrML 2.1 adopted the MPEG-7 way of defining country codes: having > a simple type with a restriction specifying the format of the string > (two/three characters, letters/numbers, etc.). Concern was raised that > this did not account for codes like "AI" which "represented 'French > Affars and Issas' (today Djibouti) in ISO 3166-1 until 1977, [and] was > [later] reused for Anguilla." This is a problem when rights expressions > lie around for 50 years or so and the meaning of their territory changes > because of this. > > Thus, the need for a versioning scheme was identified. MPEG did some > research leading up to the CR00002 that was submitted. The following > things were discovered: > > -- > > Q. Will ISO reuse codes again in the future? > A. "The ISO 3166/MA can and will make use of this possibility of > reassignment if no other reasonable solution can be found." and "During > a transitory period of at least five years after the withdrawal the code > elements will not be reassigned to different country names." > > -- > > Q. How can one reference a particular meaning of an ISO code? > A. "Yes that's a problem, ISO 3166-1 is being updated continually. So > the list that is valid now is not the one given in the fifth edition of > ISO 3166-1 from 1997. This does not mean however, that the basic > document is reissued and reprinted. Standards are revised normally every > five years. ISO 3166-1 will be revised by a standards committee starting > this year. That means that the rules under which the standard operates > are revised if necessary and that an up-to-date list of country codes > will be included in the standard. > > > In order to identify the status of your list of codes you can say > something like: ISO 3166-1:1997 plus ISO 3166-1 Newsletters up to and > including No. V-5 (NB: The V in the Newsletter numbers means fifth > edition). That says that your basic list is from the 1997 edition and > you have included all Newsletter since then." > > Thus, it seems that V-5 is not actually a version number so much as a > newsletter number. Perhaps it could be used as a version number, but is > that the intent? Is this the version number that UBL uses, or is the > version number there a version number assigned by the person writing the > schema? > > -- > > Concern was also raised about implementations being forward compatible. > For instance, if I have an implementation written in 1977 that > recognizes "US" as "United States" and "AI" as "French Affars and Issas" > and I encounter a license written in 1987 with code "US", how do I know > that the meaning of that code hasn't changed and that I can go ahead and > process it, whereas I cannot process "AI"? Thus, the idea was to use > the date of introduction so, in 1987, "US" would still have an > introduction date of 1977 and be recognizable to the 1977 > implementation, whereas "AI" introdate 1987 wouldn't be. > > Maybe it is hard to look up the introduction date, though, as I seem > only to be able to find the latest version. > > -- > > So I guess there are two questions: do we use date or version? If we > use date, do we use date or introductionDate? If we use version, do we > use version or introductionVersion? > > -- > > Your ideas/input would be greatly appreciated, > Thanks in advance, > Thomas. -- Eve Maler +1 781 442 3190 Sun Microsystems cell +1 781 883 5917 XML Web Services / Industry Initiatives eve.maler @ sun.com -- Eve Maler +1 781 442 3190 Sun Microsystems cell +1 781 883 5917 XML Web Services / Industry Initiatives eve.maler @ sun.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC