This makes good sense but I think we
need
to seriously consider:
1. Are the ATG2 datatype schemas as mature as
necessary
for UBL 2.0? How soon will there be an update to
the ATG2
datatype schemas?
2. Related to 1. - If we make specialized
datatypes based
on the ATG2 datatypes to fill in perceived gaps,
will the gaps
be better filled by ATG2 (or UBL/ATG2) and if this
is likely
in near future, wouldn't it be better to wait for
this?
This makes me tend towards a view that we might be
best to
wait for a further version of the ATG2 schemas
before
importing them raw into UBL.
Obviously this is orthogonal to the matter that
there
seem to be no technical reasons for waiting; in
my
view the reasons would just be business domain
ones.
All the best
Steve
----- Original Message -----
Sent: Wednesday, May 04, 2005 3:30
AM
Subject: Re: [ubl] Prototype -ver-sdg-4
(polymorphism / ATG2 CCTS schema alignment)
In response to Stephen's points 7 and 8, i think as a matter of
principle we should establish that our goal is to rely entirely on the ATG2
CCTS schemas and import them without modification. otherwise why
bother?
Indeed the only reason we have to maintain these ourselves is
that we dont have a central repository from UN/CEFACT to point to. They should
be a 'black box' to us.
We can, of course, define our own Specialized
Datatypes but these must be based on ATG2 Unspecialized/Unqualified Datatypes
even if this causes us some pain.
Stephen Green wrote:
7. There will likely need to be consideration
of the fact the ATG2 CCTS schemas have their own codelist schemas associated
with them and examination of how these should
relate to UBL codelist schemas. For this demonstration all the ATG2 schemas
have been imported into the UBL schemas with the
ATG2 schemas completely unchanged. 8. Regarding the Amount and the
Measure and Quantity datatypes in the ATG2 schemas, a real concern is
that there seems to me to be reliance on use of
a namespace rule to provide some of the essential (to
business and legal parties) metadata such as the
associated codelist and codelist version IDs. My concern is
that these namespaces will not make it into
instances and so may be lost for future examiners of the
documents. I'd very strongly suggest remedying
this with UBL specialized datatypes (as for UBAmount in UBL 1.0)
but I'm not sure whether/how this may be
achieved without the appropriate attributes existing in the ATG2
'unqualified datatypes'. I've not attempted to
resolve this issue in these prototypes. Rather I have used the ATG2
Amount in place of the UBL 1.0 UBLAmount but I'd
not recommend this in practise. Perhaps, in the worse case
scenario, the UBL 1.0 Specialized Datatypes
schema and dependancy schemas should be continued into UBL 2.0. This
might be undesirable since the UBLAmount forces
use of the 0.3 version of the currency codelist which might need
updating for UBl 2.0. An alternative would then
be to keep the UBL 1.0 unspecialized datatypes schema in UBL 2.0
(imported from UBL 1.0 along with imports of the
ATG2 1.1 schemas) and to base new UBL 2.0 specialized datatypes on
that.
Best Regards
Stephen Green
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
--
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
(coming soon from MIT Press)
http://mitpress.mit.edu/catalog/item/default.asp?sid=632C40AB-4E94-4930-A94E-22FF8CA5641F&ttype=2&tid=10476
|