Re: [ubl-lcsc] ** Please Review UBL Model 1.0 draft 3 as a proposed final 1.0 model ** (sent earlier)

["Stephen Green" <stephen_green@seventhproject.co.uk>]

Folks

 

Hi

 

Looking at the CCTSpec and the datatype question

regarding YearMonth, I'm fairly sure that we couldn't

or wouldn't wish to use a DataType. The reason is

1. a DT has to be derived from a CCT by extension or

restriction (as Sue pointed out in NDRSC)

2. we wouldn't wish to use as a base type any type

that lost its 'date' characterisation (as Eduardo pointed out)

3. I'm pretty sure we cannot restict or extend a date or

date_time to get a YearMonth because a pattern

based on date can only take values, even after

restriction, which are technically *legal*. So 2004-02, say, 

could never be a legal value for a date, even a restricted date.

Therefore what would be needed, to my mind, is a new

CCT, as Sue suggested, with some date-related base like

a union of xsd:date and xsd:gYearMonth (to allow either format)

(Incidentally, is a union of CCTs allowed as a user defined

DataType?)

 

** If unions can be used for CCTs, I'd *very* much like to propose

one to allow EITHER xsd:date OR xsd:dateTime. Usually one

needs to cater for either of these in all sorts of date entities. **

 

 

4. The alternative would be to restrict cct:TextType or the like

and in doing so lose the recognition of a value as a part

of an ISO date. This could be a UBL DataType, but would be

less than desirable, technically speaking, since it can only

be validated with parsers as a string and not as a date or

part of a date.

 

All the best

 

Steve

----- Original Message -----

From: Stephen Green

To: ubl-lcsc@lists.oasis-open.org

Sent: Friday, February 06, 2004 1:00 PM

Subject: [ubl-lcsc] ** Please Review UBL Model 1.0 draft 3 as a proposed final 1.0 model ** (sent earlier)

Greetings

 

Having pondered today the matter of an apparent

requirement or wish for a YearMonth DataType, I've

come to the conclusion that there are too many

issues for debate to meet the deadline for 1.0.

One issue for example is that, as I think Sue suggested,

it might be better to propose it as a new CCT. Others

include the fact that we don't use xsd:choice in UBL

and so we'd probably need something like two

separate BBIEs ExpiryDate and ExpiryYearMonth

each of which would be optional and implementers

would have to accept that either or even both might

be used (the latter probably incorrectly ??). All this

would need debate. Not least is the fact that we'd have

to spend some time examining and reveiwing how, for

the first time, we implement the CC naming rules and

CCT metadata, etc whether there need be any

Supplementary Components and the like. All too much

for me to do alone and all in one day and really I need

to get the draft model out today (which in Asia is almost

 over).

 

So I can almost see Tim's glee as I back down on

this one :-)

 

** This means I'll suggest we take 1.0 draft 3, that posted

earlier today, as the draft for review for 1.0 final. **

 

Phew.

 

Also, I'll start to look at the instances and FPSC Specs

in the light of the Schemas I sent out earlier, hoping

that the finally accepted versions will be the same or

won't be far removed from these. The sample will need

some changing to adopt the split reusable data

(CAT and CBT) but I hope I can do this with some

confidence that in the timescale available it won't have to

be radically changed again. I expect Ken will be thinking

similarly :-)

 

All the best

 

Steve