DocumentSpecification examples (was RE: issue resolution updates)

["Kanaskie, Kurt A (Kurt)" <kkanaskie@lucent.com>]

All,

I'm struggling with the details of the use of the DocumentSpecification
(a.k.a. Schema in pre-issues list) attributes "location" and "logicalModel".
I need tangible examples. I've included two simple examples, one based on
OAG BODs and one based on hypothetical ebXML messages. There are a few
aspects I would like you to consider, 1.) the fact that OAG has a DTD per
message whereas ebXML (hypothetically) does not. 2.) the fact that OAG uses
the same message (AckPO) for positive and negative acceptance. See the
isSuccess element. 3.) the fact that OAG and other standards besides ebXML
do not have a logical model. 4.) the values to use in the location,
logicalModel and BusinessDocument->name. I think it makes sense for the
BusinessDocument name to be the top level XML element name of the business
document.

Here are the example XML fragments:

<!-- an OAG document specification and transaction -->
<DocumentSpecification name="ProcessPO"
location="http://www.openapplications.org/BusinessDocuments/process_po_007.d
td">
 <BusinessDocument name="PROCESS_PO_007"/>
</DocumentSpecification>
<DocumentSpecification name="AckPO"
location="http://www.openapplications.org/BusinessDocuments/acknowledge_po_0
07.dtd">
 <BusinessDocument name="ACKNOWLEDGE_PO_007"/>
</DocumentSpecification>
<DocumentSpecification name="CancelPO"
location="http://www.openapplications.org/BusinessDocuments/acknowledge_po_0
07.dtd">
 <BusinessDocument name="ACKNOWLEDGE_PO_007"/>
</DocumentSpecification>
<BusinessTransaction name="OrderBT">
 <RequestingBusinessActivity name="OrderBA">
  <DocumentFlow businessDocument="PROCESS_PO_007" isSuccess="true"/>
 </RequestingBusinessActivity>
 <RespondingBusinessActivity name="OrderConfirmationBA">
  <DocumentFlow businessDocument="ACKNOWLEDGE_PO_007"
isSuccess="//STATUSLVL='00'"/>
  <DocumentFlow businessDocument="ACKNOWLEDGE_PO_007"
isSuccess="//STATUSLVL='99'"/>
 </RespondingBusinessActivity>
</BusinessTransaction>

<!-- an ebXML document specification and transaction -->
<DocumentSpecification name="ebXML"
location="http://www.ebxml.org/BusinessDocuments/ebXML.xsd"
logicalModel="http://www.ebxml.org/LogicalModels/ebXML.mdl">
 <BusinessDocument name="PurchaseOrder"/>
 <BusinessDocument name="ConfirmPurchaseOrder"/>
 <BusinessDocument name="DenyPurchaseOrder"/>
</DocumentSpecification>
<BusinessTransaction name="OrderBT">
 <RequestingBusinessActivity name="OrderBA">
  <DocumentFlow businessDocument="PurchaseOrder" isSuccess="true"/>
 </RequestingBusinessActivity>
 <RespondingBusinessActivity name="OrderConfirmationBA">
  <DocumentFlow businessDocument="ConfirmPurchaseOrder" isSuccess="true"/>
  <DocumentFlow businessDocument="DenyPurchaseOrder" isSuccess="false"/>
 </RespondingBusinessActivity>
</BusinessTransaction>


Sorry about the long lines.
Regards,
________________________________________________________________
Kurt Kanaskie
Lucent Technologies
kkanaskie@lucent.com
(610) 778-1069 Note the new number!

 -----Original Message-----
From: 	James Bryce Clark [mailto:jbc@lawyer.com] 
Sent:	Wednesday, April 18, 2001 10:50 AM
To:	Karsten Riemer
Cc:	ebxml-bp@lists.ebxml.org; ebxml-core@lists.ebxml.org
Subject:	Re: issue resolution updates

Karsten - Tweaks to your 4/17 log of resolutions:

<KR>
>5.  We will leave cardinality between the renamed entities 
>DocumentSpecification and BusinessDocument as one-to-many. 
>This means that a new business transaction must be defined for 
>each flavor of its document exchange.  For example 
>CreatePurchaseOrder_OAG using OAG documents, and
>CreatePurchaseOrder_X12 using X12, etc. etc. The group feels 
>this is the only safe thing to do. Any attempt to allow generic 
>transactions with parameterized document choice is too ambitious 
>(whimps!).

a.  Both the BPSS and your undoubtedly fair, unbiased record of the
deliberations should note that the bulk of the group (and maybe all) thinks
that parameterized document choice is the correct way to go, but cannot be
rolled out in a stable and reasonably reliable form by the 1.0 ship date.

b.  It's "wimps."  

>6. We leave logicalModel as the only linkage to the CC context model. 
>So in the renamed DocumentSpecification element "location" points 
>to where the actual content model of the BusinessDocument is, and 
>"logicalModel" points to where the CC context model for the 
>BusinessDocument is. If the latter is blank, the BusinessDocument 
>is assumed to not have been created using CC context model. 

a.  Of course, the latter can also point to other [schemes].   BPSS should
say so, if we can come up with the right neutral word for [schemes]
encompassing X12, RNIF, OAG, etc.
b.   Although it will be beyond a simple XML parser to confirm this, a
wellformed DocumentSpecification should contain (point to) only
BusinessDocuments that are interpretable by a named logicalModel.   (E.g.,
if you send X12 over ebXML, you are entitling the recipient to rely on and
commit you based solely on his valid application of the logicalModel your
process named to the X12 docs he gets. )   Here's my straw man answer:  Any
user or writer of a BP who wants to "legally" rely on the meaning of an X12
850 PO had better specify the X12 space in the logicalModel, or else he's
taking the chance that his counterparty will reach its own interpretation,
and attempt to bind him to it.  
c.   By implication from (b), BusinessDocuments that have no associated
logicalModel pointer had better be self-explanatory.  What would
"self-explanatory" really mean, in our context?   How do we want trading
partners to be entitled to interpret a BusinessDocument sent in the absence
of a logicalModel pointer?   Here's my straw man answer:  Any user or
writer of a BP who populates the BP solely with components that are (i)
composed wholly of XML,  and (ii) drawn from the registry where the BP
resides, should be able to happily and confidently omit the logicalModel
pointer.  Anyone else is cruising for a bruising.   

>7. There was no support for simplifying ebXML process specification 
>by allowing Business Transaction to be its own BinaryCollaboration, 
>instead of requiring a wrapping BinaryCollaboration. Proposal 
>dropped (whimps!).

I don't think the BPSS needs to say anything about this.  However, your
undoubtedly fair, unbiased record of the deliberations should note that
the idea was rejected not on merit -- the group has no problem with finding
and eliminating redundant objects -- but rather because the group
recognizes the need to maintain the model's carefully-balanced and
negotiated set of parameters at this stage, and feels that design churn for
a non-essential purpose this close to the 1.0 ship date would  endanger our
ability to deliver.  

Being in California, I will use "YUFUROTD" instead of "your undoubtedly
fair, unbiased record of the deliberations" from now on, to conserve
electricity.  

Cheers  Jamie

James Bryce Clark
Spolin Silverman & Cohen LLP 
310 586 2404    jbc@lawyer.com    


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-bp-request@lists.ebxml.org