|
Peter,
It's not clear how much supporting this use case adds versus
the complexity downside. Particular issues with the proposed solution
include:
- This requires the application message components be broken
down (into SOAP modules or separate message elements) precisely in terms of
their relation to CONTEXT or ENROL messages. Assuming the support for
multiple transaction contexts in the same application message is a worthwhile
use case (again, that's not clear), this is very easy to get wrong.
Potential errors include:
- nested elements with different reference
attributes
- CONTEXT and / or ENROL messages without an ID attribute but
in a list of such messages (if it's not related, why is it in the same
bundle? is this an error?)
- CONTEXT and / or ENROL messages with an ID attribute but no
referring portion of the application message (is this semantically identical
to leaving the attribute out for one or more members of the list of
messages?)
- When referring to a particular (named) CONTEXT or ENROL
message, I believe you meant "IDREF" attribute. As mentioned below, that
might not be the best XML choice.
- You're planning to define and name the ID and IDREF
attributes in the BTP namespace for the XML binding? If not, any random
ID or IDREF could have these semantics, leading to interoperability
problems. If so, keep in mind adding new namespace-qualified attributes
to existing application content is not simple -- their schema likely prevents
such extensions.
- What about other uses of the ID attribute on the CONTEXT and
ENROL messages? This wording prevents uses such as explicitly signing
those elements.
- Generally, the ID and IDREF XML datatypes are rather poorly
used. Some of the problems come from document-wide uniqueness
requirements for ID values and conflicts in messages that combine earlier
messages. XML Schema supports these types but
provides other similar (and significantly more complicated) ways to provide
some of the same features. Many protocols have avoided IDREF (in
particular) completely, preferring to use a URL of type
XFragment.
thanx,
doug
----- Original Message -----
Sent: Tuesday, 18 December 2001 05:37
Subject: RE: [bt-spec] BTP Issue 83 : BTP message related to *part
of* application message - 0.9.0.3 solution
BTP Issue 83 : BTP message related to *part of* application
messageSubmitter: Choreology
Category: minor
technical
Description:
In the SOAP bindings, any and all
application message in the SOAP-Body is related to the appropriate BTP
messages in the SOAP-Header. It is possible to conceive of applications where
a compound *application* message has parts that are intended to be in one BT,
some in another (almost certainly atoms within the same cohesion).
A relationship between a particular BTP message (CONTEXT or ENROL) and part
of an application message could be indicated using the ID and REF mechanisms
of XML. There would be significant implications for the application at each
end, which has got to sort out which BT applies, but the basic protocol
mechanism would be easy to specify.
The
latter changes to the SOAP binding specification, from 3879, specifiy the solution to
this:
Only CONTEXT and ENROL
messages are related (&) to application messages. If there is only one
CONTEXT or one ENROL message present in the SOAP-Body, and it does not have an
XML ID attribute, it is related to
the whole of the application message in the SOAP-Body. If a CONTEXT or ENROL
message has an XML ID attribute, it is related only to those parts of the
application message that reference it (using an XML REF attribute). There can be
multiple such CONTEXT or ENROL messages, each with an XML ID attribute. If there
are multiple CONTEXT or ENROL messages and any do not have an XML ID attribute,
such message are not related any of the application message in the
SOAP-Body.
Note -- Whether the
relatedness has any significance for the application (particularly in the case
of ENROL, without an ID parameter, carried with a response), is a matter for the
application.
Is this correct in terms of XML ? (it was written in a bit of a
hurry)
Does it make sense of itself
Peter
|