Clarification of negative vote from SAP

[jon.bosak@sun.com]

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
&#8220;identification&#8221;, the term
&#8220;identification&#8221; MUST be removed. If the
representation term of the supplementary component dictionary
entry name is "text", the representation term MUST be removed.

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>&quot;Receivals Clerk&quot;</ccts:Examples>
</ccts:Component>

Because, the object class is not "Contact", it is "Accounts Contact"!!!

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...

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

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