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


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

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

Subject: Re: [ubl-lcsc] [code] possible amendment to codelist strawmanschemas


Just to ellaborate on my previous message, explaining why I think we need these changes to the strawman prototype:

I'm informed by XML Spy, regarding the previous reference to xsd:token within the codelist schemas, that we can't base a simpleContent/restriction on a simpleType.

Changing the simpleType to a complexType prevents the use of the attributes. 

However the attributes *may* not be needed if we replace the simple base type (xsd:token - probably to be xsd:normalisedString soon) with the Core Component Type 'CodeType' which already includes these attributes. 

This of course requires that the CoreComponentTypes schema be imported and the namespace referenced. 
It also requires that the complexType/simpleContent change to simpleType and one has to drop the element declaration too (it is already declared in a schema which imports the codelist schema). 

Happily it means that we don't need to change the CoreComponentType schemas and just need to add imports to the codelist schemas to the Reusable schemas (and probably most of the document schemas). 

It seems to me to make sense to reference codelists from documents and core components from codelists anyway. 

This is just so long as we don't need to use set default values for the attributes of the cct:CodeType within the codelist schemas - then it could get scary.

All the best


>>> "Stephen Green" <stephen_green@bristol-city.gov.uk> 09/04/03 19:02 PM >>>

I've found a few problems with the 'strawman' codelist proposal example schemas.

I'd propose amended schemas as attached.

The were a few chages I found necessary but the end result seems to me to achieve the stated aims (documentary changes would probably be necessary though). Through shortage of time I can only give a brief summary of changes and will try to improve on this later.
I referenced the StatusCodeType in the 'Use' schema and that type then referenced the CodeType in the Core Component Types schema. A few other changes were necessary. This allowed changes between simpleType, simpleContent and complexType which I found to be necessary.

All the best


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