|
Stephen,
I agree that we should be using qualified datatypes when
ATG2 unqualified datatypes are insufficient. My comment was specifically related
to the use of unqualified datatypes.
I think we need to talk about using version attributes at
the next PSC call. There may be a business requirement use it based on
comments I've seen from Tim Benson.
Regards,
Sylvia
From: Stephen Green
[mailto:stephen_green@seventhproject.co.uk]
Sent: Tuesday, September
06, 2005 9:25 AM
To: swebb@gefeg.com; 'Tim McGrath'; 'Peter Larsen
Borresen'
Subject: Re: Changes of code types
Mmm.. I don't think it is less of a use of
the
ATG2 datatypes to add our own qualified
datatypes. Just to do so as an example
to
others might justify it but it would still be
better,
I think, to only do so if the ATG2
unqualified
datatype Amount is insufficient. This was
what
we agreed was the case when in 1.0 we
added
the UBLAmount (admittedly though it
wasn't
an alternative to the ATG2 udt:Amount but to
the
CCTS conceptual unqualified Amount):
we
wanted to limit the codelist version to - was
it
0.3 or 3.0 I can't remember - and to fix
the
relevant attribute to that. Now, however,
I'd say
we should avoid fixing any version attribute
as
a rule since it precludes backwards
compatibility
later when in a minor version we wish to
change
to a newer version say.
My conslusion is that we don't want to fix
the
version of the currency codelist used with a
major
version Amount (as it might have to change
in
minor versions) but to allow users to
specify
which they use (and therefore be able to
change
it without having to progress to another
major
version). So we ought not fix it. Then
the question
is: Is the ATG2 udt:Amount appropriate for
this
without
specialization/qualification?
By the way, I think we should be having this
conversation on the list at this
point.
All the best
Steve
----- Original Message -----
Sent: Tuesday, September 06, 2005 4:26
PM
Subject: RE: Changes of code types
I think we're missing the real objective here. We
are producing publicly available documents. Our NDR say we are using
ATG2 uDT. Our spreadsheets and schema need to match what we are claiming in
the NDR and other publicly available documents like the UBL email
archives.
Regards,
Sylvia
From: Tim McGrath
[mailto:tmcgrath@portcomm.com.au]
Sent: Tuesday, September 06, 2005
6:52 AM
To: Stephen Green; Peter Larsen Borresen; swebb@gefeg.com
Subject: Re:
Changes of code types
Then we need to communicate this to sylvia so she can discuss it
with david.
I will copy her on this message.
(Sylvia, sorry to
bring you in late on this thread but I thought it was something we could do
without you - it appears not!)
Stephen Green wrote:
Tim, Peter
this is what David produced in the draft 2
phase 0 UBL 2.0 schemas for UBLAmount
<!-- ===== Type Definitions ===== -->
<xsd:complexType name="CurrencyCodeType">
<xsd:simpleContent>
<xsd:extension base="clm54217:CurrencyCodeContentType">
<xsd:attribute name="listID" type="xsd:normalizedString" fixed="4217"
use="optional"/>
<xsd:attribute name="listAgencyID" type="xsd:normalizedString" fixed="5"
use="optional"/>
<xsd:attribute name="listAgencyName" type="xsd:string" fixed="ISO"
use="optional"/>
<xsd:attribute name="listName" type="xsd:string" fixed="Currency"
use="optional"/>
<xsd:attribute name="listVersionID" type="xsd:normalizedString" fixed="2001"
use="optional"/>
<xsd:attribute name="name" type="xsd:string" use="optional"/>
<xsd:attribute name="languageID" type="xsd:language" fixed="en"
use="optional"/>
<xsd:attribute name="listURI" type="xsd:anyURI"
fixed="http://www.bsi-global.com/Technical%2BInformation/Publications/_Publi
cations/tig90x.doc" use="optional"/>
<xsd:attribute name="listSchemeURI" type="xsd:anyURI"
fixed="urn:un:unece:uncefact:codelist:draft:54217:2001" use="optional"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<xsd:complexType name="UBLAmountType">
<xsd:simpleContent>
<xsd:restriction base="udt:AmountType">
<xsd:attribute name="currencyID" type="clm54217:CurrencyCodeContentType"
use="required"/>
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType>
this is in the specialized datatypes schema
and there are entries like
<xsd:complexType name="PriceAmountType">
<xsd:simpleContent>
<xsd:extension base="sdt:UBLAmountType"/>
</xsd:simpleContent>
</xsd:complexType>
in various places in the CBC schema
(i note in passing though that some BBIEs in David's CBC
have
<xsd:complexType name="ExtensionAmountType">
<xsd:simpleContent>
<xsd:extension base="udt:AmountType"/>
</xsd:simpleContent>
</xsd:complexType>
)
So obviously he found it was possible to get the sdt UBLAmount
into schemas but I don't know how he did it. I doubt he had to hand
edit it all (there are so many sdt:UBLAmountType BBIEs) but
he might have had to do some 'hard-coding' of the schema generator.
In essence I think it very important, for the integrity of the tool at
least,
to ensure this acn be done. To my mind reverting all UBLAmount
datatypes to Amount would be a last resort and that I'm not convinced
it is necessary.
All the best
Steve
----- Original Message -----
From: "Tim McGrath" <tmcgrath@portcomm.com.au>
To: "Peter Larsen Borresen" <plb@itst.dk>;
<stephen_green@seventhproject.co.uk>
Sent: Tuesday, September 06, 2005 10:32 AM
Subject: Re: Changes of code types
good point!
i think we should check with Stephen as he made a comment on today's
call that made me think we dont need to do this. He felt that EDIFIX
can deal with this (it is a known issue) but it may mean Sylvia needs to
talk to David (their programmer).
stpehen - sylvia found that the specialized data types are not
understood when she loads into EDIFIX and we were planning to just
remove the code list qualifiers (column j) and revert all specialized
data types back to their CCTS parent. But do you think we dont need to?
Peter Larsen Borresen wrote:
Hi Tim
I am about to change the code types, but it strikes me, that we loose a
lot
of information. Do we really want to change Line Status Code type to Code
type, currency Code type to Code type etc. ?
/Peter
--
regards
tim mcgrath
phone: +618 93352228
postal: po box 1289 fremantle western australia 6160
DOCUMENT ENGINEERING: Analyzing and Designing Documents for Business
Informatics and Web Services
http://mitpress.mit.edu/catalog/item/default.asp?sid=632C40AB-4E94-4930-A94E-22FF8CA5641F&ttype=2&tid=10476
--
regards
tim mcgrath
phone: +618 93352228
postal: po box 1289 fremantle western australia 6160
DOCUMENT ENGINEERING: Analyzing and Designing Documents for Business Informatics and Web Services
http://mitpress.mit.edu/catalog/item/default.asp?sid=632C40AB-4E94-4930-A94E-22FF8CA5641F&ttype=2&tid=10476
|