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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

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


Subject: Re: [ubl] A Codelist Issue


At 06:38 AM 3/12/2004 +0800, Tim McGrath wrote:
>i sympathize with tony's view.  what we are dealing with in enumerations 
>are not the same as extended the data structures.   it also appears to be 
>a case of if parties wish to do this, they will anyway, . so i am not sure 
>what mandating against it achieves.
>
>i also what to recognise that this is only one issue for code list 
>representation.  they are other (i suggest more significant) decisions to 
>be made.

Let me propose a design that you may not have thought of. It is a bit 
kludge but a very XML way of solving this schema issue. It may not go along 
with the need for introducing a namespace change, but one clean way to add 
values to the schema, without technically requiring someone to edit the 
schema files is to use external entities. For every code list an entity and 
the associated file would be created. This entity would then be referenced 
at the end of the code list definition. As delivered this file would be 
empty, but as someone needs to modify the list they could add values in the 
external entities file. It certainly is portable and gets around the 
restrictions of extending an enumerated type.

So you have something like:
<!ENTITY iso3660extensions   SYSTEM "iso3660extensions.xml">

<xs:simpleType name="CountryCodesType">
      <xs:enumeration value="US"/>
      <xs:enumeration value="UK"/>
      <xs:enumeration value="FR"/>
      <xs:enumeration value="DU"/>
         &iso3660extensions;
  </xs:simpleType>

Schema source may not be 100%, but I think you get the idea.

It has the advantage of not introducing a bunch of schema features, keeps 
all extensions in the same file. Restrictions you would handle the same as 
restrictions on element content.

Just a thought anyway, I know it is a bit kludgey, but some of the 
alternatives can be as ugly.

..dan



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