[Fwd: Re: Starting point (not ending point) for "steps" document]

[Anne Hendry <anne.hendry@sun.com>]

-------- Original Message --------
Subject: Re: Starting point (not ending point) for "steps" document
Date: Thu, 11 Mar 2004 11:25:07 +0800
From: Tim McGrath <tmcgrath@portcomm.com.au>
To: Burnsmarty@aol.com
CC: lseaburg@aeon-llc.com, stephen_green@seventhproject.co.uk, 
anne.hendry@sun.com, mark.palmer@nist.gov, jon.bosak@sun.com
References: <1cc.1ba2bd9f.2d8104f1@aol.com>



i hoep this gets through in time for discussion in the TTSC call on 
thursday - unfortunately i cannot make another 1:00am call, so i hope my 
notes are good enough.

i have gone through this and made comments and changes based on what i 
think is happening.  my XSd knowledge is pretty thin so i may have made 
false assumptions.  however, a key point this identifies is that we need 
to be more formal with CodeListName and make sure it reflects what we 
want the data type to be called.  i suspect we may need to update our 
models to correct this.  The other thing we need to take a closer look 
at is the CoreCompoentParameter schema - it seems to be out -of-date and 
out of alignment.

whilst i now feel the mist is clearing in terms of how to build code 
list schemas, i am now unsure how we are supposed to reference these in 
our specialised data type schema.  in fact, it would appear from this as 
though the specialised data type schema does nothing that this code list 
schema doesn't do.

in other words, if we do what marty says (and i like this approach), why 
can't we have a document schema reference the code list schema directly? 
for example the  Invoice.TaxCurrencyCode could be of data type 
cur:CurrencyCode, instead of sdt:CurrencyCode as it would be now.

perhaps someone can demonstrate (using this example) what a specialised 
data type schema entry for currency code would be and why we need it?  

in fact, this gives weight to the argument that what we try and call 
specialised data types are actually instances of unspecialised data 
types - not new types in their own right.  if we don't want to add or 
remove attributes/supplementary components for codes, then the only data 
type we actually need is CodeType.  i suspect this is what David and 
Michael were doing when they tried to put all the codelist values into 
the SDT schema. perhaps they recognised that these (SDT and CL schemas) 
were doing the same job.

could it be we can simplify this architecture even more? :-P

Burnsmarty@aol.com wrote:

> Tim, Stephen, et al.,
>  
> I am forcing this draft out tonight so that you, Tim and Stephen, can 
> get to look at it after a well deserved nights sleep. Please see if 
> this follows your data model and explains how to create a schema. I 
> have embedded the actual spreadsheet I used (version 8).
>  
> Note that this version of code list schema generation is eliminates 
> the CLUDT namespace. I have coded the schema so that it only requires 
> the xsd namespace for primitive types.
>  
> The best way to comment is to edit it and email it back so I can bring 
> it forward.
>  
> Thanks and good night,
> Marty


-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160

How to go from spreadsheet to schemas-tim-mar11.doc