Spec/Schema Inconsistencies

I've come across a couple small problems while trying to complete WD
19, and have guessed at appropriate resolutions (subject to review &
approval, of course).  There may be more like this to be found, as no
one has yet made a thorough comparison between the spec, schema and
examples.


CORE-112
According to 5.2.2.12, PayloadInfo contains @xml:id and @eb:version
attributes.  Uncertain where a reference to this @id would be useful,
as a Signature would point to the payload data itself.  A version
attribute appears further down, at
PayloadInfo/PartInfo/Schema/@version, which seems appropriate.  So
the one at this level appears to be extraneous.  Neither schema nor
examples contain these attributes.
Proposal: remove both attributes.


CORE-113
5.2.2.13 states that eb:PartInfo/Schema/@namespace is REQUIRED, yet it
appears neither in the schema nor in examples.  Propose to make it
OPTIONAL and add it to the schema.  Also clarify that
eb:PartInfo/Schema/@version is also OPTIONAL (leaving only @location
REQUIRED).


And calling to your attention to Issue CORE-111 (from my previous
message on namespace & versioning):
> Messaging/@version
> attribute adds no useful information that is not already communicated
> via the namespace declaration, so it could be removed.  (version="3.0"
> is not just a semantic variant of the previous header structure; it is
> a completely new schema/namespace.)

I propose to remove eb:Messaging/@version, because it needlessly
complicates MSH implementations.  If the processing semantics of the
eb:Messaging element are changed, I would prefer to signify this
through a namespace change (either at the eb:Messaging level, or for
individual sub-elements, depending on where the change has occurred).
The alternative requires building specialized processing into the MSH,
to change behavior based on the contents of the @version string.

In case this is too controversial, I will prepare drafts both with and
without it, so we can choose which variant to send to public review.


--Pete
Pete Wenzel <>
Join the Open ESB Community <http://open-esb.org/>