legalxml-courtfiling — archive

[Scott Came]

 MHonArc v2.5.0b2 -->

















legalxml-courtfiling message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]








Subject: Re: [legalxml-courtfiling] Second unresolved agenda item




From: "Scott Came" <scott@justiceintegration.com>
To: "Electronic Court Filing Technical Committeee" <legalxml-courtfiling@lists.oasis-open.org>
Date: Tue, 31 May 2005 18:56:04 -0700 (PDT)







Hi Dallas.

This diagram is intended to apply only to the Web Services Messaging Profile.� (It is intended
to go into the strawman specification in the WS MP section.)� I would hope other profiles would provide a similar
diagram or other description of how the parts of a complete message fit together for transmission between MDEs.

As the diagram doesn't get into the contents of the message body, it doesn't show where "embedded"
documents would go.� But it certainly doesn't preclude them, should they be included in the message structure schema
for a particular message.

Do we have a requirement in the requirements document for the "version
controls" feature you mention below?� If it would be implemented in SOAP headers in the WS MP, I would think it
would be a non-functional requirement.

> It is my understanding that we have agreed that the standard is
not restricted to one specific Communication layer.
> With that in mind, we should take the SOAP Message
Package out of the discussion.  I also believe in previous
> discussions that we agreed to allow the documents
to be embedded in the body or to be included as attachments such as
> that which is defined below.  I would
anticipate that there should be two diagrams depending on which one an
> implementation desires otherwise we
are binding ourselves to require the SOAP messaging layer as identified in your
> diagram.
>
> Also, from my previous message I believe that the standard clearly needs to define version controls which I
think
> should reside in the SOAP Header area.  The standard also needs to define how that process works with
intermediary
> nodes.
>
> Dallas
>
>
>