From: Tim
McGrath [mailto:tmcgrath@portcomm.com.au]
Sent: Thu 6/01/2005 6:27 PM
To: Ram Kumar
Cc: jon.bosak@sun.com
Subject: Re: CIQ
V3.0 schemas
as we
discussed, i have tried to map the xAL-3.0.5 schemas to the UBL
1.0 Address
BIE. the results are included in the attached
spreadsheet.
WHAT DOES
THE COLOR CODES (YELLOW AND PINK) IN THE SPREADSHEET
REPRESENT?
these represent the concepts of the ebXML Core
Component Technical Specification...
white rows are Basic Business
Information Entities (BBIE or in XML terms these are implemented as the
elements)
pink rows are Aggregate Business Information Entitites (ABIE or
in XML terms these are implemented as complex types)
yellow rows are
Association Business Information Entities (ASBIE or in XML terms these are
nestings of one ABIE within another)
From this it appears that we still have some
issues with naming and
design rules. For example CIQ uses attributes for
business information
entities or core components - UBL only uses
elements.
I AM NOT
CLEAR HERE. CAN YOU EXPLAIN THIS WITH AN EXAMPLE?
FOR YOUR
INFORMATION, IN XAL AND XNL, EVERY ELEMENT USES ATTRIBUTES TO DEFINE
A
CODE AND
CODE TYPE THAT IS USED BY POSTAL AUTHORITIES TO REPRESENT AN
ELEMENT.
WE ALSO
HAVE ATTRIBUTES TO DEFINE THE TYPE OF ELEMENT AND ALSO
TO DEFINE
SEPARATORS SUCH AS "-","/","No.", ETC USED BY ORIGINAL DATA AND WE CANNOT
AFFORD
TO LOOSE
ANY PIECE OF ORIGINAL DATA.
UBL is based on the ebXML CCTS core component
types. So one BBIE can only be one of Amount, Binary Object, Code,
DateTime, Identifier, Indicator, Measure, Numeric, Quantity or Text (as
primary representation terms) or Graphic, Picture, Sound, Video, Date,
Time, Value, Rate, Percent or Name (as secondary representation terms) data
types. Each of these data types is implemented as a simpleType in XSD
and its attributes are given to us by the ebXML Core Component Technical
specification. It means UBL (and any other ebXML CCTS vocabulary) should
only be defining elements and their higher structures.
In your case we
end up having to map UBL elements to xAL attributes. The actual case in
point was the use of addressDetailsID as an attribute of AddressDetails
- whereas in UBL this is an element called ID within the Address structure.
The idea used in xAL and xNL of having codes and types for each
element is at odds with the basic concepts of Core Components. in fact,
it harks back to the old ambiguous EDI standards that we have been trying to
get away from. depending on what code types are used the structures
could mean completely different things - this makes interoperability very
difficult even when both parties use xAL or xNL.
My personal opinion is
that the logical extension of this "code plus type" thinking leads us to only
needing one element with two attributes to describe anything in the whole
universe. one to the define the value and the other to explain what it
is. clearly this is not realistic and the correct direction is to be
more explicit about the meaning of elements in their primary definition and
close the opportunity for ambiguity.
Also,
there is an obvious difference in the conceptual models used by
UBL and
xAL. For example, can you explain the criteria for deciding
why
BuildingName is at one level and Premise details at another? or
why
there is AddressLines with children of AddressLine and at another
level
there is FreeTextAddressLine?
YOU ARE
CORRECT. THIS WAS AN OVERSIGHT AS IT IS ONLY A DRAFT
VERSION.
what was the oversight? and what should it have
been? the question is really what analytical methods were applied to
make structural design decisions?
THANKS
FOR POINTING THIS OUT. IF YOU SEE ANY FURTHER ISSUES,
PLEASE
LET US KNOW.
it would help if you have some conceptual model that
describes the
business rules xAL uses.
WE ARE WORKING ON
IT.
IT WILL
BE GREAT IF YOU CAN LOOK INTO THE POSSIBILITY OF USING XNL
SPECS.
THAT
DESCRIBES PARTY NAME.
my concern is that i had thought you were moving the
work of CIQ closer to that of ebXML Core Components and UBL Naming and Design
Rules but if anything this version moves away from these specifications.
i suspect we will have difficulty converging with the xNL model for
Party Names for similar reasons.
I LOOK
FORWARD TO YOUR COMMENTS.
Regards,
Ram
Ram Kumar wrote:
>Dear
Tim,
>
>It was great catching up at the OASIS Conference
>in
Sydney.
>
>As discussed and agreed, please find enclosed the draft
version
>of the schema (xAL-Basic V3.0) that we have been
working
>on for the past couple of months. This schema uses some of
the
>UBL NDR for defining elements and attributes. Not all UBL
NDR
>could be used because CIQ specs. are used for various
applications
>and not just shipping, purchase order, invoicing, etc.
This V3.0
>draft address schema is used by CIQ TC to map the UPU
international
>addresses (about 170+ country addresses have been mapped
so far).
>
>I have also enclosed Party (a person or
organisation)
>Schema (xNL-Basic V3.0) that I want UBL to seriously
consider re-using
>it in the next version. This schema supports about
36+ party name
>formats that exists in 240+ countries.
>
>As
suggested by you, it would be great if you can look into it
>and make
recommendations on what has to be done to make it
>compatible to Core
components.
>
>The new schema is a flat structure compared to the
previous one,
>but does not loose the flexibility offered by the
previous one.
>
>I am very keen to see "strong convergence"
between UBL and CIQ work in
>the party name and address area and other
party information specs
>that CIQ TC has produced (eg. telephone, email
addresses,
>other contact details, etc) in the future. This convergence
should
>set an example to other TCs within OASIS on how the TCs should
re-use
>work atleast within OASIS first.
>
>Looking forward
to hearing from
you.
>
>Regards,
>
>Ram
>
>Ram
Kumar
>General Manager
>Software R&D and
Architecture
>MSI BUSINESS SYSTEMS
>Suite 204A, 244 Beecroft
Road
>Epping, NSW 2121, Australia
>Direct: +61-2-9815
0226
>Mobile: +61-412 758 025
>Fax: +61-2-98150200
>URL: www.msi.com.au
>
>
>
--
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
Also,
there is an obvious difference in the conceptual models used by
UBL and
xAL. For example, can you explain the criteria for deciding
why
BuildingName is at one level and Premise details at another? or
why
there is AddressLines with children of AddressLine and at another
level
there is FreeTextAddressLine?
YOU ARE
CORRECT. THIS WAS AN OVERSIGHT AS IT IS ONLY A DRAFT
VERSION.
THANKS
FOR POINTING THIS OUT. IF YOU SEE ANY FURTHER ISSUES,
PLEASE
LET US KNOW.
it would help if you have some conceptual model that
describes the
business rules xAL uses.
WE ARE WORKING ON
IT.
IT WILL
BE GREAT IF YOU CAN LOOK INTO THE POSSIBILITY OF USING XNL
SPECS.
THAT
DESCRIBES PARTY NAME.
I LOOK
FORWARD TO YOUR COMMENTS.
Regards,
Ram
Ram Kumar wrote:
>Dear
Tim,
>
>It was great catching up at the OASIS Conference
>in
Sydney.
>
>As discussed and agreed, please find enclosed the draft
version
>of the schema (xAL-Basic V3.0) that we have been
working
>on for the past couple of months. This schema uses some of
the
>UBL NDR for defining elements and attributes. Not all UBL
NDR
>could be used because CIQ specs. are used for various
applications
>and not just shipping, purchase order, invoicing, etc.
This V3.0
>draft address schema is used by CIQ TC to map the UPU
international
>addresses (about 170+ country addresses have been mapped
so far).
>
>I have also enclosed Party (a person or
organisation)
>Schema (xNL-Basic V3.0) that I want UBL to seriously
consider re-using
>it in the next version. This schema supports about
36+ party name
>formats that exists in 240+ countries.
>
>As
suggested by you, it would be great if you can look into it
>and make
recommendations on what has to be done to make it
>compatible to Core
components.
>
>The new schema is a flat structure compared to the
previous one,
>but does not loose the flexibility offered by the
previous one.
>
>I am very keen to see "strong convergence"
between UBL and CIQ work in
>the party name and address area and other
party information specs
>that CIQ TC has produced (eg. telephone, email
addresses,
>other contact details, etc) in the future. This convergence
should
>set an example to other TCs within OASIS on how the TCs should
re-use
>work atleast within OASIS first.
>
>Looking forward
to hearing from
you.
>
>Regards,
>
>Ram
>
>Ram
Kumar
>General Manager
>Software R&D and
Architecture
>MSI BUSINESS SYSTEMS
>Suite 204A, 244 Beecroft
Road
>Epping, NSW 2121, Australia
>Direct: +61-2-9815
0226
>Mobile: +61-412 758 025
>Fax: +61-2-98150200
>URL: www.msi.com.au
>
>
>
--
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
--
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