Cardinality of payload (Was description of Specification Metamode )

[Cory Casanave <cory-c@dataaccess.com>]

Karsten,
Thanks to a lively MM meeting I did not have a chance to raise an issue, one
that also came up in Tokyo.  I am referring to the cardinality of the
"payload" relation from "Message" to "Composite Information Entity".  In
your model you have this as 1..* while I thought it was agreed that it was
1.  This question being does a message carry a single composite document or
multiple composite documents.

If the message carries multiple composite information entities I would make
the case that it is just another composite.  The things you want to say
about the "composite message", such as naming of sub-elements, cardinalities
and security parameters are in every case the same things you want to say
about the elements of a composite.  In addition, you want to deal with this
composite message as a "type", you want to store it, log it, transform it,
reuse it, bind to it...  This fits with the internet computing paradigm of
document interchange and the power of this paradigm is that everything
exchanged is a document.  If message is just another composite why do you
need it?

You do need a way to say that a document is exchanged as part of a
commercial transaction - this is what the message should be for.  

If on the other hand we change to a message exchange paradigm it becomes the
message type, not the document type that drives the system and this message
type is not reusable, named or generally available for processing  like we
would process a document type (I.E. storing and manipulating in a log).  So
we have introduced another typing system and all the inherent overhead for
supporting another typing system.  I can't think of any advantages of this
new typing system that could not be handled with composite information
entity.

The alternative approach would be to have message inherit from composite
information entity, suggesting that is a special kind of composite.  But,
because of the relations to commercial transaction this would make it a
single use type - something that should be avoided.  

All of this does not imply that the underlying technology may not want some
kind of envelope, but I don't think we want to model that at the this level.
In addition we want the technology to be able to send non-XML data that may
be referenced by the document (I.E. pictures of people in the document), but
this should also be part of the technology binding.

So, this is a long winded way of saying that the cardinality of the payload
relation should be "1" and composite messages should be modeled as a
composite information entity.  I have no idea if this is an emotional issue
with anyone or just an oversight.  If anyone has thoughts perhaps we should
get them out so this can be resolved next week.

Cory

> -----Original Message-----
> From:	Karsten Riemer [SMTP:Karsten.Riemer@East.Sun.COM]
> Sent:	Monday, November 27, 2000 11:14 AM
> To:	ebxml-bp@lists.ebxml.org
> Cc:	cory-c@dataaccess.com
> Subject:	description of Specification Metamodel
> 
> Hi,
> Tomorrow we will have our weekly metamodel meeting.
> 
> The weekly BP/CC metamodel meeting is scheduled for 28 Nov. at 9 am PST,
> 12 pm
> EST.
> 
> To access the call, dial 888-699-0348 domestically and +1 732-336-6000
> internationally, with  a PIN of 4894#.
> 
> Paul, could you please forward this to CC list since my e-mails to that
> list
> bounce.
> 
> Last week I presented the specification metamodel to the metamodel
> meeting,
> but not everyone had the handout yet. For this week's meeting I have
> included
> the same handout in a more complete description of the metamodel,
> attached.
> 
> Last week the following issues were raised:
> Need for subtype of role into agent and service.
> Need for specification of timing/security on both halves of a commercial
> transaction. Need for re-use of core process constructs.
> 
> The last of these issues are addressed in the attached. The first two will
> be
> addressed after more discussion tomorrow. After tomorrow's meeting I will
> create an issues list to keep track of all all of this is we move toward a
> submission to QR end of December.
> 
> Also discussed last week was the need for new names for the views of the
> metamodel. In the attached document I am using the word "Analysis
> Metamodel"
> in place of the word "Methodology Metamodel", this seems a little better,
> but
> I am open to further suggestions.
> 
> thanks,
> -karsten << File: Word.Document.8 >>