[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issues (typos) with the sample CPP's and sample CPA (version 2.0b)
Hi CPPA team
When working on the CPA composition process I came across a couple of
oddities in the official example CPP's. If these have been reported
earlier, please excuse this email.
The files under question are the "official" CPPA example CPP's and
example CPA version 2.0b.
Link to files:
CPP A:
http://www.oasis-open.org/apps/org/workgroup/ebxml-cppa/download.php/238/cpp-example-companyA-2_0b.xml
CPP B:
http://www.oasis-open.org/apps/org/workgroup/ebxml-cppa/download.php/246/cpp-example-companyB-2_0b.xml
CPA:
http://www.oasis-open.org/apps/org/workgroup/ebxml-cppa/download.php/253/cpa-example-2_0b.xml
Orignially I wanted to report these oddities earlier (about 1 year ago)
but could not get the email to the OASIS mailinglist. It seems the
oddities survived from CPPA 1.0 version to CPPA 2.0 version.
People really like examples, so they should be fixed. For the CPA
composition of my project I even took the example CPP's as primary test
input.
Please find a list of issues I came across.
file: cpp-example-companyA-2_0b.xml
-----------------------------------
1)
<tp:PartyRef ...></tp:PartyRef>
missing xlink:type="simple" attribute to make it consistent with other
party's PartyRef.
file: cpp-example-companyB-2_0b.xml
-----------------------------------
1)
CaseSensitive seller vs Seller issues. Again to make it consitent and
look nice.
suggestion to change from:
<tp:Role
tp:name="Seller"
xlink:type="simple"
xlink:href="http://www.rosettanet.org/processes/3A4.xml#seller"/>
to:
<tp:Role
tp:name="Seller"
xlink:type="simple"
xlink:href="http://www.rosettanet.org/processes/3A4.xml#Seller"/>
2)
<TransportSender> and <TransportReceiver> elements of company B dont
have <tp:AccessAuthentication>digest</tp:AccessAuthentication> whereas
the those elements of company A have.
Probably this can be left as is as this is a case where the CPA
composition and later the CPA negotiation have to deal with the
cardinality of the element <tp:AccessAuthentication>. In the sample CPA
the <tp:AccessAuthentication>digest</tp:AccessAuthentication> element is
removed from party B's PartyInfo.
3)
The Composite id is probably wrong in the following Packaging:
<tp:Packaging tp:id="CompanyB_RequestPackage">
<tp:ProcessingCapabilities
tp:parse="true"
tp:generate="true"/>
<tp:CompositeList>
<tp:Composite
tp:id="RequestMsg"
tp:mimetype="multipart/related"
tp:mimeparameters="type=text/xml">
<tp:Constituent tp:idref="CompanyB_MsgHdr"/>
<tp:Constituent tp:idref="CompanyB_Request"/>
</tp:Composite>
</tp:CompositeList>
</tp:Packaging>
I suggest to change the id attribute from:
tp:id="RequestMsg"
to:
tp:id="CompanyB_RequestMsg"
In the example CPA tp:id="CompanyB_RequestMsg" is used.
file: combination cpp-example-companyA-2_0b.xml and
cpp-example-companyB-2_0b.xml
---------------------------------------------------
0)
Each SimplePart element, in both example CPP's, have a value (URI) of
the pattern:
<NEW_LINE><SPACE><SPACE><SPACE><SPACE><SPACE><SPACE><VALUE><NEW_LINE><SPACE><SPACE><SPACE><SPACE>
in hex view:
0a20 2020 2020 20 <VALUE> 0a20 20 20 20
Maybe for the example CPP's removing the newline and spaces might be
helpful, to provide clean samples.
One NameSpaceSupported in company A
(/tp:CollaborationProtocolAgreement/tp:SimplePart[5]/tp:NamespaceSupported) even has 4 leading spaces compared to others 6 leading spaces ...
This might bring up a discussion to think over certain string XML schema
data types. XML Schema provides features to make sure that strings have
all white spaces collapese, all leading and trailing spaces removed, all
tabs, new lines, carrige returns removed. There are built-in data types
such as "normalizedstring".
1)
Typo:
company A:
CanSend/ThisPartyActionBinding[@id="companyA_ABID2"] has action name
"ReceiptAcknowledgement"
CanReceive/ThisPartyActionBinding[@id="companyA_ABID4" has action name
"ReceiptAcknowledgment"
company B:
CanSend/ThisPartyActionBinding[@id="companyB_ABID2"] has action name
"ReceiptAcknowledgement"
CanReceive/ThisPartyActionBinding[@id="companyB_ABID5"] has action name
"ReceiptAcknowledgment"
based on the action name we should have the following pairs:
companyA_ABID2 - companyB_ABID5
companyA_ABID4 - companyB_ABID2
a CPA composition tool should not find these pairs because their action
name has a typo (extra 'e'), eg they dont match.
suggestion to change all occurances of "ReceiptAcknowledgement" to
"ReceiptAcknowledgment".
The sample CPA also has the extra "e" typo.
As a side note it is not obvoius why the name of the action is
"ReceiptAcknowledgment" and not "Receipt Acknowledgment" as all other
action names. But it does not matter as long as they are the same in
both CPP's.
more issues
-----------
Here is a list of conflicts the CPA composition algorithm picked up. The
algorithm did figure out which pairs (CanSend against CanReceive,
SimplePart against SimplePart etc) to compare. Then when comparing
elements and attributes the following issues showed up.
Legend:
ref_x_cpp: is the XPath expression to the problem element/attribute in
the CPP, where x is party A or party B
x_value: is the value which is set in the CPP, where x is party A or
party B.
Suggestions:
I suggest to set both elements/attributes to the same value.
conflict list:
1)
ref_a_cpp='/tp:CollaborationProtocolProfile/tp:SimplePart[1]/tp:NamespaceSupported/@tp:location'
ref_b_cpp='/tp:CollaborationProtocolProfile/tp:SimplePart[1]/tp:NamespaceSupported/@tp:location'
a_value='http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd'
b_value='http://www.oasis-open.org/committees/ebxml-msg/schema/draft-msg-header-05.xsd'
comment: different .xsd file referenced.
2)
ref_a_cpp='/tp:CollaborationProtocolProfile/tp:SimplePart[1]/tp:NamespaceSupported'
ref_b_cpp='/tp:CollaborationProtocolProfile/tp:SimplePart[1]/tp:NamespaceSupported'
a_value='http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd'
b_value='http://www.oasis-open.org/committees/ebxml-msg/schema/draft-msg-header-05.xsd'
comment: different .xsd file referenced.
5)
ref_a_cpp='/tp:CollaborationProtocolProfile/tp:SimplePart[3]/tp:NamespaceSupported/@tp:location'
ref_b_cpp='/tp:CollaborationProtocolProfile/tp:SimplePart[3]/tp:NamespaceSupported/@tp:location'
a_value='http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd'
b_value='http://www.oasis-open.org/committees/ebxml-msg/schema/draft-msg-header-05.xsd'
comment: different .xsd file referenced.
6)
ref_a_cpp='/tp:CollaborationProtocolProfile/tp:SimplePart[3]/tp:NamespaceSupported'
ref_b_cpp='/tp:CollaborationProtocolProfile/tp:SimplePart[3]/tp:NamespaceSupported'
a_value='http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd'
b_value='http://www.oasis-open.org/committees/ebxml-msg/schema/draft-msg-header-05.xsd'
comment: different .xsd file referenced.
3)
ref_a_cpp='/tp:CollaborationProtocolProfile/tp:SimplePart[5]/tp:NamespaceSupported/@tp:location'
ref_b_cpp='/tp:CollaborationProtocolProfile/tp:SimplePart[5]/tp:NamespaceSupported/@tp:location'
a_value='http://www.rosettanet.org/schemas/PurchaseOrderConfirmation.xsd'
b_value='http://www.rosettanet.org/schemas/PurchaseOrderConfirmation.xsd.xsd'
comment: different .xsd file referenced.
4)
ref_a_cpp='/tp:CollaborationProtocolProfile/tp:SimplePart[5]/tp:NamespaceSupported'
ref_b_cpp='/tp:CollaborationProtocolProfile/tp:SimplePart[5]/tp:NamespaceSupported'
a_value='http://www.rosettanet.org/schemas/PIP3A4PurchaseOrderConfirmation.xsd'
b_value='http://www.rosettanet.org/schemas/PIP3A4PurchaseOrderConfirmation.xsd'
Case 4 is because of the above "spaces" problem but is there are reason
that the NamespaceSupported element value and its location attribute
have a different URLs (or URI?) of the .xsd XML Schema file.
Unfortunately the current version of the CPA composition algorithm has
its own limitations, such as no synchronous CanSend/CanReceives checks
and thus no synchronous Transport, Packaging, DeliveryChannel elements
checks. Further does the algorithm not check Certificates. The reason
for these limitations are time constraints. I hope to fix them somewhen
next year.
What these issues show me, is that the sample CPA is created by hand ;)
Kind regards.
Sacha Schlegel
--
------------------------------------------------
Sacha Schlegel
------------------------------------------------
4 Warwick Str, 6102 St. James, Perth, Australia
sacha@schlegel.li www.schlegel.li
public key: www.schlegel.li/sacha.gpg
------------------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]