Ram,
Yes - I'd not forgotten - I'm laggardly behind on
that task - but I have
been swamped with work load.
I'm just finishing all the editing and fine tuning
to release CAM V1 as
official OASIS spec', and then I have to work on
BPSS model
examples so we can move V2 to OASIS spec'
too.
Once I get done that task - I will be able to
return more fully to
CAM, CIQ and CCTS. I hate it when I get on too many critical
paths. Fortunately Martin Roberts has been a
huge asset
working on the noun representation in registry in
this regard
so we have been able to move on parallel paths here
- not
just serial paths.
I need a cloning machine so I can make a few more
Martins!!
Cheers, DW
----- Original Message -----
Sent: Tuesday, January 11, 2005 7:24
PM
Subject: RE: [ciq] FW: CIQ V3.0
schemas
David,
Thanks. We know that CAM templatets can
be used to transform an xAL representation into
say another representation (say, UBL,
Hr-XML, etc). One of your outstanding task is to
map the xAL data into HR-XML and vice
versa and I gaave you a sample address data represented
in both xAL and HR-XML. If you can give
the results, we can always use it to promote CAM
as part of CIQ initiative.
Regards,
Ram
From: David Webber (XML)
[mailto:david@drrw.info] Sent: Wed 1/12/2005 10:11 AM To:
Ram Kumar; fulton.wilcox@coltsnecksolutions.com Cc:
ciq@lists.oasis-open.org Subject: Re: [ciq] FW: CIQ V3.0
schemas
Ram,
I'm presenting on the 14th @ DHS here in Wash DC
on CAM and CCTS. I think that will
help toward the alignment here.
Basically I see that one-to-one equivalence
between a CCTS worldview and a CIQ view is
not necessarily at odds - CCTS should not be
dictating what is attributes or elements.
Basically with CAM you can use them
interchangably (solves the basic flaw in DTDs and
now Schema) by allowing you to apply typing and
validation to them equally.
But as a general rule of thumb I use attributes
to qualify aspects of an element. This
is kinda intuitive:
e.g. <font color="red" style="arial"
size="3"/>
and <address type="postal" style="business"
locale="USA">
The production rules for a UML model of a UBL
address can then be geared up to
output accordingly - since parents have children
and elements have parameters
within the UML model of the class diagram.
Then the production rules can output
both the structure (XSD) and the CAM template
(rules) as needed. This separation
makes for a much cleaner system. Notice
also that rules and definitions can be
stored into registry business noun semantic
definitions (XSD and/or CAM syntax)
and instead of the UML model tool having to guess
or hack at all this - it simply
references the UID of the appropriate item from
the registry.
E.g.
<standard_usa_postal_address_format
as:setUID="usps_101">
and so on.
We can discuss this more following on from the
14th present and I'll make
available the slides and feedback. The
notion of "address" and "person"
is one example use
case I'm discussing there.
Thanks, DW
----- Original Message -----
Sent: Tuesday, January 11, 2005 5:36
PM
Subject: RE: [ciq] FW: CIQ V3.0
schemas
Hi Fulton,
Thanks for your comments. Please see my
comments below in bold.
From: Fulton Wilcox
[mailto:fulton.wilcox@coltsnecksolutions.com] Sent: Wed 1/12/2005
1:43 AM To: Ram Kumar; ciq@lists.oasis-open.org Subject:
RE: [ciq] FW: CIQ V3.0 schemas
All,
Is there some unifying principle
– e.g., “data goes in elements, metadata
in attributes” that indicates the proper way forward for all concerned? Is
there some “negative” principle, like don’t have an attribute for an
attribute, that suggests use of an element (or otherwise)? Presumably we do
not want to move in the wrong direction because of
“legacy.”
Also, the “customer” for both
CIQ and UBL is, for example, someone running a global ERP that is holding
and importing/exporting many thousands of sets of customer identity
(including some fields and flags beyond the scope of CIQ). Is the choice
being debated likely to be of practical significance to that someone with
respect to ease and attractiveness of adoption of the CIQ and UBL standards?
As an example, does the
preservation of separators (meaningful, I gather, to postal authorities)
imply that those separators need to be imported into SAP address fields
(which are held at ship-to, bill-to, etc.)? Are those extra characters
really behavior indicators that should be “normalized” - linked to something
else – e.g., jurisdiction?
PLEASE NOTE THAT ALL THE
SEPARATORS, INDICATORS, ETC ARE DEFINED IN THE ADVANCED
VERSION OF THE SPECS. ONE CAN
ALWAYS USE THE BASIC VERSION OF THE SPECS. THAT
DOES NOT HAVE THESE
FIELDS.
Ram
Regards,
Fulton Wilcox
Colts Neck Solutions LLC
From: Ram
Kumar [mailto:RKumar@msi.com.au] Sent: Monday, January 10, 2005 9:38
PM To:
ciq@lists.oasis-open.org Subject: RE: [ciq] FW: CIQ V3.0
schemas
By moving CIQ to align with
ebXML CC is completely re-defining the goal of CIQ TC which is to be
application independent. ebXML/UN CEFACT CC in the current form can
never support party name and address application requirements and probably
will ever. if they look at UPU, USPS, CEN Postal organisation requirements,
they will understand why. This is my view. We can get rid of the attributes
to support postal services codes and use namespace references instead. That
is fine. But, what about the other attributes that are required to ensure
that
no original data (eg.
separators, indicators, locators, etc) is lost when represented in xNAL?
From:
Colin.Wallis@ssc.govt.nz [mailto:Colin.Wallis@ssc.govt.nz] Sent: Tue 1/11/2005 1:28 PM To: Ram Kumar;
ciq@lists.oasis-open.org Subject: RE: [ciq] FW: CIQ V3.0
schemas
Well, for one, I
don't know ebXML CCTS in enough depth to either challenge or support Tim's
views. Who do we know who can take an independent view for
us?
I think it is
an important point - one of those watershed/crossroads kind of points
that justifies real attention.
Integrated OASIS
standards is probably a "holy grail" that is not ever completely
attainable, and David Webber will say "jCAM can map between CIQ
and UBL so why the worry?" (won't you David!:-)). Fair
enough.
A: Tim's
views turn out to be correct, and
B: we
think that ebXML CCTS is going to turn out to be a fundamental building
block long term ...
then there is value
is pausing for a moment to decide if we could and (if so) should
redesign CIQ so we have the greatest chance of take up going
forward.
It would be a
major departure from CIQ's original roots. And there is an
argument in favour of saying "why should we?" There is also an
argument along the lines of Mohammed and the mountain. In this case,
which is really which?
-----Original
Message----- From: Ram
Kumar [mailto:RKumar@msi.com.au] Sent: Tuesday, 11 January 2005 11:59
a.m. To:
ciq@lists.oasis-open.org Subject: [ciq] FW: CIQ V3.0
schemas
From: Tim
McGrath [mailto:tmcgrath@portcomm.com.au] Sent: Mon 1/10/2005 6:02
PM To: Ram
Kumar Cc:
ciq@lists.oasis-open.org; jon.bosak@sun.com Subject: Re: CIQ V3.0
schemas
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
|