Re: AW: Updates to Schema generations

[<stephen_green@seventhproject.co.uk>]

David

Apologies that I missed one point:

The format Supplementary Component is to be added back into the
'DateTime', 'Indicator' and 'Numeric' types 

I was told in the meeting yesterday that you would be able to somehow
discourage folk from using it (since it is made redundant by the 
use of the xsd datatypes.


Regarding the codelists and the SDT Schema Module, we are actually
seeking to implement the NDR rules and the resolution of the group 
to not use substitution Groups so, although I sympathise with your
wish to defer an immediate change (perhaps to see if there is any
comeback), it should be firm ground that we make the changes decided in 
the meeting. The SDT remains and the codelist schema modules are as
agreed. The content of the SDT is not really something agreed till
now so it shouldn't be a matter of going back on any previous
agreements. It is less controversial, in my opinion, than removing the
CLUDT. I'll leave it to you.

All the best

Steve



Mike wrote:

Greetings, 

As mentioned in a previous email, and not included below, the latest CCT
schema still has 'DateTime', 'Indicator' and 'Numeric' types defined as
simple types (with a *Restriction* on the built in type). 

I believe we had agreed in Washington that they would be redefined to
conform to the CCTS. That is, the required supplementary component
'Format' would be added to the definition of each. 

I wasn't able to make yesterday's meeting (until the end, anyway) and
Jon has made it very clear that that is where the decisions are made;
however, this involves CCTS conformance and, if I am not mistaken, the
decision was made in joint session with Tim and Steve on the phone, so
there was good representation of all concerned SCs. 

Thank You, 

Mike Grimley 










Message from Grimley Michael J NPRI <GrimleyMJ@Npt.NUWC.Navy.Mil>
forwarded on 18.03.2004, 15:01:31:
> 


David Kruppke <kruppke@gefeg.com> wrote on 18.03.2004, 15:06:19:
> Hello Stephen and Tim,
> 
> please find enclosed a draft-8.31.zip. It contains a inofficial version only
> for you in preparation for the call tomorrow.
> 
> The following items have changed:
> 
> 1. Reusable
>  TaxSchema.Currency now refers to the appropriate specialised datatype
> 
> 2. Reusable
>   Payment Means. Payment_ Means Type refers Payment Means_ Code instead of
> ..4461.
> 
> 3. Truncation of text in the specialised datatype schema module is removed
> 
> 4. The codelist schema modules have move from "codelist\use" into "codelist"
> 
> 5. Unspecialised datatype DateType is based on xsd:date
> 
> 6. Unspecialised datatype TimeType is based on xsd:time
> 
> 7. The names of the codes are in the schemas and look like Stephens proposal
> (...)
> 
> 8. Code values and names corresponds to the latest supply from Anne.
> 
> 
> The codelist issue has not touched. It is a lot of work to change all the
> models. If the decision is stable we do this work immediately. Most likely
> after the call tomorrow.
> 
> 
> Stephen,
> 
> thank you very much for giving me a summary. It helped a lot.
> 
> 
> I have problems with the following:
> 
> 
> (2)  This Specialised DataTypes Schema Module will only need to be imported
> into the Common Basic Components Schema Modules.
> 
> 
> Why? I understand it is actually empty?
> 
> 
> 
> Regards, David.
> 
> 
> 
> 
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Stephen Green [mailto:stephen_green@seventhproject.co.uk]
> Gesendet: Mittwoch, 17. März 2004 21:39
> An: David Kruppke
> Cc: Stephen Green; Michael Dill; Tim McGrath
> Betreff: Updates to Schema generations
> 
> 
> David
> 
> Hi.
> 
> Good progress was made today on the joint conference calls. (I've attached a
> copy of Anne's notes for reference, should you want them. Other issues
> perhaps
> not included, could probably be found in Tim's notes/minutes which will
> probably
> be published later. However, I hope I can present the required changes
> clearly
> enough now so that you can implement them. Feel free to contact me directly
> if necessary by e-mail or, if you prefer, at work on +44 117 9223794 between
> UDT 9.00am and 3.00pm tomorrow. I'm not sure whether I'll be able to make
> the 4.00pm UDT Tools call since I have to make a 1.00pm UDT call on Friday.)
> 
> The decisions made lead to the following change requests for Schema
> generation
> as we move close to a final 1.0 release. (I'd note that there was discussion
> about another
> issue, that of the Core Components Parameters Schema Module, which is to be
> defered until *after* the following changes, as another iteration.)
> 
> Changes Requested
> 
> (1)  The Codelist Schema Modules should be treated as being Specialised
> DataType
> Schema Modules. They are to remain as separate Codelist Schema Modules but
> the existing Specialised DataTypes Schema Module will no longer be used to
> reference
> the Codelist Schema Modules. Instead it will be almost empty (similar to how
> it was in beta
> as the 'DataTypes Schema Module'). I would predict it looking like this (if
> it is generated for draft 8):
> 
> 
>  
> 
> 
> [with the usual UBL Header comment block too]
> 
> or, if Tim releases his draft 9 very soon, like this:
> 
> 
>  
> 
> 
> [In the following examples I'll just keep to the draft-8.4 scenario.]
> 
> 
> (2)  This Specialised DataTypes Schema Module will only need to be imported
> into the Common Basic Components Schema Modules.
> 
> This is because the Code and Identifier BBIEs are the only ones declared
> outside of the CBC Schema and of these two types the only relevant one is
> likely to be code which has its specialised datatypes defined in the
> separate codelist schema modules (a special type of SDT Schema) and not now
> in the 'Specialised DataTypes Schema Module'.
> 
> 
> 
> 
> (3)   The 'use' subfolder within the 'codelist' folder is to be dropped and
> all the codelists schema modules just placed in the 'codelist' folder
> 
> 
> (4)  With the change in the non-codelist SDT Schema Module in (1) above, the
> other Schema Modules will
> need to reference the Codelist Schema Modules directly, i.e.:
> 
> targetNamespace="urn:oasis:names:tc:ubl:CommonAggregateComponents:1:0-draft-
> 8.4"
> xmlns:res="urn:oasis:names:tc:ubl:codelist:AcknowledgementResponseCode:1:0-d
> raft-8.4"
> ...
> xmlns:cur="urn:oasis:names:tc:ubl:codelist:CurrencyCode:1:0-draft-8.4"
> xmlns:sdt="urn:oasis:names:tc:ubl:SpecialisedDatatypes:1:0-draft-8.4"
> xmlns:udt="urn:oasis:names:tc:ubl:UnspecialisedDatatypes:1:0-draft-8.4"
> xmlns:cbc="urn:oasis:names:tc:ubl:CommonBasicComponents:1:0-draft-8.4"
> xmlns:ccts="urn:oasis:names:tc:ubl:CoreComponentParameters:1:0-draft-8.4"
> xmlns="urn:oasis:names:tc:ubl:CommonAggregateComponents:1:0-draft-8.4"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"; elementFormDefault="qualified"
> attributeFormDefault="unqualified" version="1:0-draft-8.4"
> ...
> 
> 
> 
> 
> 
> 
> (5)  The mention of DerivedCodeType is to change to xxxxxCodeType where
> xxxxx is the Property Term of the CodeList
> e.g.  cur:DerivedCodeType becomes  cur:CurrencyCodeType
> (in future, external groups might be defining their own names for these
> codelist schema modules but we will stick to using the property from the SDT
> model)
> 
> 
> 
> (6)  Note that since the Codelist Schema Modules are now considered to be a
> kind of Specialised DataType Schema Module and that the module
> called the Specialised DataType Schema Module (of which in future there
> could be many incidentally) is almost empty in UBL 1.0, the reference
> to the type of a code having a codelist schema module from within the
> CommonAggregateComponents Schema Module or, where required,
> a Document Schema Module will look not like sdt:DerivedCodeType or
> sdt:CurrencyCodeType but for the example of the currency code like this:
> 
> 
> 
>  
>   
>  ...
> 
> 
> 
> (7)  Not, I think, a change request but more a note: In beta, the credits
> for codelist schemas defined in the codelist spreadsheet (now the SDT
> spreadsheet)
> were added to the UBL comment header block. Now they won't appear at all in
> the Schemas (as, I believe they don't anyway) but will just be held in the
> spreadsheets.
> 
> (8)  Again, not a change request but a note, since you've already started
> implementing it: The codes will all be based, not on the cct:CodeType but on
> the
> udt:CodeType (thanks)
> 
> (9)  The 'names' for codes from the codelists (the second string from the
> code text file) should appear in some way in annotation/documentation
> associated
> with the 'value' enumeration in the Codelist Schema Module.
> 
> e.g.
> 
> 
> 
>  
>   
>    
>     cur
>     ISO 4217
>     6
>     0.3
>    
>   
>  
>  
>   
>    
> 
> ...
> 
>    
>     
>      
>       United States Dollar
>      
>     
>    
> 
> ...
> 
>    
>    
>    
>    
>    
>    
>    
>    
>    
>   
>  
> 
> 
> 
> I'm not sure in this example whether you'd use this same element 
> . In the CLSC example
> an undefined prefix is hinted at but I think we have yet to see how things
> turn out with the issues around
> the use of the Core Components Parameters Schema Module - whether an element
> defined there might
> be suitable. For now I'd suggest sticking with  without a prefix
> unless you've a better idea.
> 
> 
> (10)   I was asked to correct my e-mail bug report concerning DateType - I
> wrote cct:DateType; it should of course read udt:DateType
> and the udt:DateType should be based on the xsd:date (a secondary
> representation term interpreting a udt:Date as an xsd:date just as
> UBL has a udt:Time as based on an xsd:time).
> 
> 
>  
>   
>    
>     DT
>     Date. Type
>     A particular point in the progression of time together
> with the relevant supplementary information.
>     Date
>    
>   
>  
>  
>   
>  
> 
> 
> 
> should be
> 
> 
>  
>   
>    
>     DT
>     Date. Type
>     A particular point in the progression of time together
> with the relevant supplementary information.
>     Date
>    
>   
>  
>  
>   
>  
> 
> 
> 
> So the fixes should then be made to the Unspecialised DataType Schema
> Module, according to UBL's longstanding NDR-endorsed exception to
> the udt based on cct rule, such that
> 
> 
>  
>   
>    
>     DT
>     Date. Type
>     A particular point in the progression of time together
> with the relevant supplementary information.
>     Date
>    
>   
>  
>  
>   
>  
> 
> 
> should become
> 
> 
>  
>   
>    
>     DT
>     Date. Type
>     A particular point in the progression of time together
> with the relevant supplementary information.
>     Date
>    
>   
>  
>  
>   
>  
> 
> 
> and
> 
> 
>  
>   
>    
>     DT
>     Time. Type
>     Time
>    
>   
>  
>  
>   
>  
> 
> 
> 
> should become
> 
> 
>  
>   
>    
>     DT
>     Time. Type
>     Time
>    
>   
>  
>  
>   
>  
> 
> 
> 
> (11)  Not sure what the root of this problem was but there should be no more
> code types like  4461_ Code. Type;
> all should be replaced with their text equivalents e.g. PaymentMeansCode.
> Type . I'm not sure if this is a model
> issue though.
> 
> Tim and I will meet again with anyone else at 1.00pm UDT on Friday to see
> how things can go from here, prior to
> the other call at 3.00pm UDT.
> 
> As I say, contact me if need be. I hope to help as much as I can with
> checking the resulting schemas, etc too.
> 
> All the best and good luck.
> 
> Steve