[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]