Doug,
Thanks
for these comments. I was wondering about how complex it made things - I
generally don't like having two ways of doing things in a protocol (since I
choose one and you choose the other and we dont interwork).
I
think it is quite a plausible use case, though it is only an optimisation - you
can always send two requests.
In
general, it is going to require the application protocol (and the btp, server
framework and application implementations) to have some cognisance of this. The
intent in the suggested text was to provide a way in which (bits of) application
message could point at the btp context that applied to it. I guess you can get
the same effect (with only some of the same errors) by carrying the context in
the application message itself,which you are always at liberty to do (if the
other side knows what it means, which we deem they do).
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.
yes
- ignorance on my part. (and some very ancient and partly corrupt
memories of bits of sgml)
- 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.
I
thought everything had ID and IDREF automatically ? if the CONTEXT
has an ID, and a piece of application message has an IDREF that
points to it, that's what they meant presumably.
- What about other uses of the ID attribute on the CONTEXT
and ENROL messages? This wording prevents uses such as explicitly
signing those elements.
that
would seem possible - more than one kind of thing can point at it. Would
be more complicated if the application message needed to point at btp and at
security things. Or do you mean the IDREF value would be unknown at signing
time, since the ID on the BTP message hadn't been made
then.
- 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.
Ultimately, it is up to the application, and maybe we
should just leave it entirely to the application at this stage. Strictly
speaking, even the CONTEXT & request stuff is an optional convenience for
application protocol specifiers, not something required in every
case.
Peter
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
|