Re: issue resolution updates

[James Bryce Clark <jbc@lawyer.com>]

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