It does seem like a long time since we spoke - it also nice to get your
insightful review to help ensure we have a quality product.
I have put my humble assessment against your comments.
PS. i am copying the original distribution list on this as they may be
wondering what happened to it!
Stuhec, Gunther wrote:
Hello Tim,
it is very nice to hearing from
you.
You'll find my cmments under
your comments.
Kind regards,
Gunther
I hope my comments help in explaining what may be a misunderstanding.
Perhaps we should have made clear that the vote was on the UBL package
and that the NDR document is still under development.
[GS] This is correct.
jon.bosak@sun.com
wrote:
Hello UBL TC,
Yesterday I forwarded to you the text of all the comments received
during the balloting of UBL 1.0 as an OASIS Standard, voting on
which ended 31 October. This material included comments received
from Claus Von Riegen of SAP accompanying SAP's negative vote. On
25 October I requested a clarification of those reasons from SAP,
and today I received the following response from Gunther Stuhec.
The group meeting in Santa Clara today reviewed this message and
confirmed its earlier finding that SAP has not raised any new
technical issues with the specification as published. Tim McGrath
and Mark Crawford have agreed to respond in more detail as soon as
their work this week will allow.
Jon
##################################################################
From: "Stuhec, Gunther" <gunther.stuhec@sap.com>
To: jon.bosak@sun.com
Cc: "Von Riegen, Claus" <claus.von.riegen@sap.com>
Subject: FW: SAP vote on UBL
Date: Tue, 2 Nov 2004 14:45:14 +0100
Hello Jon,
sorry for our delay. We had an public holiday. Nevertheless, I
hope our answer can be considered. We have seen the most of the
inconsistencies in the following areas:
Redundant Information in Attribute Names
========================================
We're not agree with this decision, to add all the "Object Class"
as prefix into the attribute name (see rule ATN1 in "Naming and
Design Rules"). We're thinking that some of the "Object Classes"
are only redundant in attributes names and makes the complete
element instance unecessarally huge and undreadable. Furthermore
the UN/CEFACT ATG2 is saying:
"We recognize that there currently exists inconsistencies in CCTS,
however we believe that the revised rules (se comment from David
Kruppke) provide for a consistent representation of the
supplementary components in the CCT schema module and are
consistent with OAGI input."
Therefore the ATG2 defined the following rule:
[R117] Each supplementary component xsd:attribute "name" MUST be
the ccts:supplementary component dictionary entry name with the
separators and spaces removed. If the object class of the
supplementary component dictionary entry name matches exactly with
the object class of the parent CCT, the object class name MUST be
removed. If the object class of the supplementary component
dictionary entry name contains the name of the object class of the
parent CCT, the duplicated object class word or words MUST be
removed. If the object class of the supplementary component
dictionary entry name contains the term
“identification”, the term
“identification” MUST be removed. If the
representation term of the supplementary component dictionary
entry name is "text", the representation term MUST be removed.
you will be pleased to note that the NDR document for UBL is currently
being modified to align with ATG2.
[GS] That is very nice that we'll get only
one NDR document at one time.
[TM] let us hope so
Missing ore Incorrect Definition
==================================
Some of the definitions are incorrect, like:
AccountsContact/ID
<ccts:Component>
<ccts:ComponentType>BBIE</ccts:ComponentType>
<ccts:DictionaryEntryName>Contact. Identifier</ccts:DictionaryEntryName>
<ccts:Definition>identifies the department or employee by a unique identity other than their name when given as a contact.</ccts:Definition>
<ccts:Cardinality>0..1</ccts:Cardinality>
<ccts:ObjectClass>Contact</ccts:ObjectClass>
<ccts:PropertyTerm>Identifier</ccts:PropertyTerm>
<ccts:RepresentationTerm>Identifier</ccts:RepresentationTerm>
<ccts:DataType>Identifier. Type</ccts:DataType>
<ccts:Examples>"Receivals Clerk"</ccts:Examples>
</ccts:Component>
Because, the object class is not "Contact", it is "Accounts Contact"!!!
you are correct the defintion could be tighter, but i hardly
think this is prohibitive to using UBL.
[GS] This
is only a minor comment from our site. But the semantic and the clear
and unambiguous description of this semantic is the most important
information in all BIEs. You need for all BIE a perfect description and
handling instructions. Otherwise it is not possible, to implement and
use these BIEs in the applications.
[TM] agreed - i couldn't have said it better myself.
Or many definitions are still missing, like the definitions of all BBIEs:
<xsd:element name="ActualDeliveryDateTime" type="DeliveryDateTimeType"/>
<xsd:element name="AdditionalInformation" type="InformationType"/>
<xsd:element name="AdditionalStreetName" type="StreetNameType"/>
<xsd:element name="Amount" type="AmountType"/>
<xsd:element name="BackorderQuantity" type="QuantityType"/>
etc...
UBL does not give semantic defintions for Basic BIEs. They
are defined when they are used in a context - that is, within an
aggregate structure. Using Amount as an exmaples - it will have a
different defintions when used in PriceAmount
Allowance Charge. Amount is defined as "specifies the allowance or
charge amount"
Base Price. Maximum_ Amount. Amount is defined as "specifies the
maximum amount in a range for which the price applies"
LineItem. LineExtenstionAmount is defined as "the monetary amount
that is the total for the line item, including any pricing variation
(allowances, charges or discounts) but not adjusted by any overall
payment settlement discount or taxation. (equals BasePrice multiplied
by Quantity, plus AllowanceCharges)"
[GS] This definition must be placed
within BBIE, because only this definition helps us to understand, how
we can use and implement these BIEs. Ok, "Amount" is understandable for
us. But there are BIEs defined, which must be explained in detail and
under which circumstances we have to use these BIEs - like
"AdditionalInformation" oder "BackorderQuantity". This is also the lack
of the most of the other business document standards. They can't easily
implemented into application, because the most of their definition
aren't indisputable.
[TM] unfortunately definitions will always be disputable - but i take
your point. we should be aiming for this. I also agree that it would
be beneficial for UBL common basic components to have a semantic
definition. I had hoped that we would be able to use a library of
common core components for this but it may be necessary to develop our
own. certainly this is something we will address as we move forward
into UBL 1.1.
In fact, you picked up a case where we hadn't done this very well in
your comment on AccountsContact.
Inconsistencies Element Names
=============================
There are still incosistencies in the declared element names. The
UBL NDR is saying in ELN3 tha redundant words in the ccts:ASBIE
property term or its qualifiers and the associated ccts:ABIE
object class term or its qualifiers MUST be dropped.
But in many element names have still a part of the object class
term as prefix. See following ABIE Party:
Party/cbc:MarkCareIndicator
Party/cbc:MarkAttentionIndicator
Party/PartyIdentification
Party/PartyName
Party/Address
Party/PartyTaxScheme
Party/Contact
Party/Language
I am not sure if I understand this, but I cannot see any
Qualifiers for Object Class or Properties in the Party ABIE.
If you mean that three of the associated ABIEs have a name that begins
with the word Party then these are not qualified names. It is just
that in the English language we have no better word for describing the
Object Class that describes the TaxScheme used by a Party than the term
"PartyTaxScheme", likewise with PartyIdentification and PartyName.
These are not TaxScheme qualified by Party. It is just terminology
that gives the impression the names are duplicated - it is not the true
case.
This is shown in the schema documentation as...
<xsd:element ref="PartyTaxScheme" minOccurs="0"
maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>
<ccts:Component>
<ccts:ObjectClass>Party</ccts:ObjectClass>
<ccts:PropertyTerm>Party Tax
Scheme</ccts:PropertyTerm>
<ccts:AssociatedObjectClass>Party Tax
Scheme</ccts:AssociatedObjectClass>
</ccts:Component>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
[GS] The rule [ELN3] says:
"A UBL global element
name based on a qualified ccts:ASBIE MUST be the ccts:ASBIE dictionary entry name
property term and its qualifiers; and the object class term and qualifiers of its
associated ccts:ABIE. All ccts:DictionaryEntryName
separators MUST be removed. Redundant words in the ccts:ASBIE property term or its
qualifiers and the associated"
"Party" is a redundant and
duplicate information. Therefore "Party" must be dropped.
[TM] i guess it comes down to your interpretation of 'redundant
words'. we take this to mean duplicated terms, rather than the pattern
of strings that make up a word. in other words, it is not a lexical
issue but a semantic one. the fact that the same word is contained in
the name of two different object classes or property terms does not
make one of them redundant.
We're saying also in rule
[NMC1] that each dictionary entry name MUST
define one and only one fully qualified path (FQP) for an element or
attribute. This means especially for "Party. Tax Scheme. Tax Scheme":
[TM] Do you mean Party. Party Tax Scheme or Party Tax Scheme. Tax
Scheme - we don't have a Party. TaxScheme. TaxScheme?
the three ABIEs involved are "Party", "Party Tax Scheme" and "Tax
Scheme". if it helps you can think of Party Tax Scheme as the
intersection entity of Party and Tax Scheme - it describes the Tax
Scheme for a specific Party.
Party/TaxScheme
I
guess, this fully qualified path is readable enough (also in English
language). I will also refer to the backwards reading test described in
"3_ebXML CC Naming Conventions Draft4.doc" (see attachment). If you use
the backwards reading test for the Party/TaxScheme that you'll get "The
Tax Scheme of a Party". And if you use the same reading test for
"Party/PartyTaxScheme" than you'll get "The Tax Scheme used by a Party
of a Party".
[TM] i also favour the backward reading test but i would say in this
case it reads as "The Party Tax Scheme used by a Party" and its
subsequent ASBIE is "The Tax Scheme of a Party Tax Scheme". I agree it
is ugly to think of Party Tax Scheme as one object - but it is. We
dont have a better english term - but i am there is one in german :-)
Therefore, we voted with "NO". Because, we had informed about
these inconsistencies. For example with the following mail
http://lists.oasis-open.org/archives/ubl-comment/200406/msg00004.html
especially with the sentence:
"Furthermore, we have seen that there is no consistency in the tag
names of BBIEs and ASBIEs. Some of tag names using the "Object
Class Term" and others not. Some of the tag names are prefixed by
namespace prefix and others not. This kind of inconsistency does
not allow us an efficient and reusable implementation of the
components (ABIE, BBIE and ASBIE), because ...."
Kind regards,
Gunther
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.
--
regards
tim mcgrath
phone: +618 93352228
postal: po box 1289 fremantle western australia 6160
--
regards
tim mcgrath
phone: +618 93352228
postal: po box 1289 fremantle western australia 6160
|