Re: [ebxml-dev] re BPSS: how can IidentifyDocumentEnvelopefromreceivedmessage

[nagahashi@fla.fujitsu.com]

Hima,

I really appreciate your response.

I had a look into BPSS 1.05 and found that the inconsistency regarding 
to schemaElement has been fixed. Thanks!

> Not sure what you mean by this from your earlier email
> """""If it points to message schema (I'm not sure because there is
> specificationLocation attribute), I have to validate the received
> message against all possible schemas to identify DocumentEnvelope. 
This
> sounds like a costly implementation. It would be lightweight if I 
could
> use some short identifier I can get without parsing the payload.""'"".
> Can you explain this statement?

Okay I try again.

I wrote "I'm not sure because there is specificationLocation attribute", 
because the difference of specificationID and specificationLocation is 
not clearly stated in the spec. Now I know they are alternatives with 
(mostly) the same semantics.

So, specificationID refers to an element in the schema definition "that 
defines the type of this document." I'm not sure what this means. Does 
it mean that the element pointed by specificationID should be a root 
element of the document?

If specificationID specifies the root element a valid message should 
have, then BSI will look into the message and parse it, pick the root 
element and test against the specificationID to identify 
DocumentEnvelope for the message. This requires slightly more work than 
identifying DocumentEnvelope simply by an ebXML header value (if there 
were appropriate one).

If isIntelligibleCheckRequired="true", BSI should validate the document 
against the schema specified in BusinessDocument. This must be done 
separately from the previous step ('parsing' above), since BSI cannot 
tell the document type before parsing. So BSI would parse the document 
again (with validation turned on) or keep the DOM tree to execute 
validation step on it. Although there can be some optimizations, it will 
complicates the process. 

If BusinessDocument uses specificationLocation, then BSI has to use 
validation to identify the document type. This is obviously inefficient.
You may say "You MUST use specificationID if you have multiple 
DocumentEnvelope in the RespondingActivity."... this is not stated in 
the spec.

With RNIF, you can identify document type from 
BusinessActivityIdentifier in the Service Header without looking into 
the business document. Then you can validate the business document with 
specific schema.

When we developed PoC demonstration for phase I, assumptions are that 
we'll have unique Action name for each document type. That means we can 
identify document type from a value in the ebXML header and then 
validate the document accordingly. I heard that Action are to name 
BusinessTransaction (Is this true? -- I regret I couldn't follow the 
recent discussion about semantics of Service and Action). Then my 
assumption is no more valid.

(I hope I'm communicating well this time...)

Regards
Kenji

> cheers
> hima
> 
> 
> nagahashi@fla.fujitsu.com wrote:
> 
> > Hima,
> >
> > Thank you for your reply!
> >
> > I did't know the specificationElement attribute of BusinessDocument .
..
> > Ah, It is in the class diagram on page 22! (I'm reading 1.04 draft - 
I
> > understand it is wip) I couldn't find any description for
> > specificationElement, even on page 59 (the specificationID attribute 
is
> > missing in BusinessDocument class in the diagram, too). Coudld you 
tell
> > me what should I specify in specificationElement?
> >
> > If it points to message schema (I'm not sure because there is
> > specificationLocation attribute), I have to validate the received
> > message against all possible schemas to identify DocumentEnvelope. 
This
> > sounds like a costly implementation. It would be lightweight if I 
could
> > use some short identifier I can get without parsing the payload.
> >
> > If it is an identifier, question remains: in which MSH information I 
can
> > find the identifier?
> >
> > Sorry if I missed something in other related ebXML specs.
> >
> > Thanks
> > Kenji Nagahashi
> >
> > > DocumentEnvelope references the BusinessDocument
> > > which points to a specificationElement.
> > >
> > > Based on the specificationElement in the document received
> > > over the messaging layer, this identifies the DocumentEnvelope
> > > corresponding to isPositiveResponse=false
> > >
> > > You could use the conditionExpression in the BusinessDocument, if 
for
> > e.g
> > >  same Schema is used for different BusinessDocuments but
> > > based on the conditionExpression, like presence or absence
> > > of a specific Element, they derive different DocumentEnvelopes.
> > >
> > > -hima
> > >
> > > nagahashi@jp.fujitsu.com wrote:
> > >
> > > > Hi
> > > >
> > > > I have a (possibly silly) question about BPSS. Anybody has
> > experienced
> > > > this problem? Could anybody give me an answer to it?
> > > > ----
> > > > Please assume I'm developing ebXML gateway which is configurable
> > with
> > > > BPSS and do some business process management staff for me.
> > > >
> > > > BusinessTransaction/RespondingActivity can have more than one
> > > > DocumentEnvelope. If the gateway receives a message for
> > DocumentEnvelope
> > > > with isPositiveResponse="false", the BusinessTransaction must 
fail.
> > > > In order to determine completion state of a BusinessTransaction, 
the
> > > > gateway must identify which DocumentEnvelope it received.
> > > >
> > > > Question is, which information from BPSS gives me a key to 
identify
> > > > DocumentEnvelope? Transport (ebMS) can pass many information up 
to
> > BP
> > > > manager. Which of them are used to identify DocumentEnvelope and
> > Where
> > > > is it specified in the BPSS? This is so important that there 
should
> > be
> > > > some 'standard' way.
> > > >
> > > > I found that BusinessDocument has conditionExpression. BPSS spec
> > says
> > > > this conditionExpression "determines whether this is a valid
> > business
> > > > document for its envelope." Is this it?
> > > >
> > > > Thanks in advance
> > > >
> > > > Kenji Nagahashi
> > > >
> > > > ----------------------------------------------------------------
> > > > The ebxml-dev list is sponsored by OASIS.
> > > > To subscribe or unsubscribe from this elist use the subscription
> > > > manager: <http://lists.ebxml.org/ob/adm.pl>
> > >
> > >
> > > ----------------------------------------------------------------
> > > The ebxml-dev list is sponsored by OASIS.
> > > To subscribe or unsubscribe from this elist use the subscription
> > > manager: <http://lists.ebxml.org/ob/adm.pl>
> >
> > ----------------------------------------------------------------
> > The ebxml-dev list is sponsored by OASIS.
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.ebxml.org/ob/adm.pl>
> 
> 
> ----------------------------------------------------------------
> The ebxml-dev list is sponsored by OASIS.
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.ebxml.org/ob/adm.pl>