Re: DocumentSpecification examples (was RE: issue resolution updates)

[Karsten Riemer <Karsten.Riemer@east.sun.com>]

Kurt,
this is very timely, since the POC intends to show the use of multiple
document 'libraries' within one big multiparty collaboration. I am also very
glad that you continue exploring the use of ebXML specschema for use by OAG.

-karsten

>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