Re: [ubl] Re: AW: Updates to Schema generations

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

Just to note, regarding the changes requested yesterday, in particular those
relating
to the SDT Schema Module and the Codelist Schema Modules, the changes would
bring us more fully into line with our NDR rule
"Each code list used in the UBL schema MUST be imported individually.

CDL7] An xsd:Import element MUST be declared for every code list required in
a UBL schema."

I think it best if this could be implemented the way we decided by dropping
the use

of the SDT module to carry the namespaces to codelist schemas and to let
these be

referenced directly from the Schemas where the codes are used.



All the best

Steve





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

From: <stephen_green@seventhproject.co.uk>
To: <ubl@lists.oasis-open.org>
Cc: "Stephen Green" <stephen_green@seventhproject.co.uk>;
<tmcgrath@portcomm.com.au>; "Michael Dill" <dill@gefeg.com>
Sent: Thursday, March 18, 2004 3:16 PM
Subject: [ubl] Re: AW: Updates to Schema generations


>
> 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
>
> To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/ubl/members/leave_workgroup.php
.
>
>