[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] Clarification of negative vote from SAP
|
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. 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. you are correct the defintion could be tighter, but i hardly think this is prohibitive to using UBL.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"!!! 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 PriceAmountOr 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... 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)" In fact, you picked up a case where we hadn't done this very well in your comment on AccountsContact. I am not sure if I understand this, but I cannot see any Qualifiers for Object Class or Properties in the Party ABIE.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 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> 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]