Open XML Markup Compatibility

["Fraser Goffin" <goffinf@hotmail.com>]

A while back I posted a question about use of the Must Ignore Unknown 
(retain/discard) pattern described (primarily) by David Orchard as an 
approach to processing XML instances containing allowable content that MAY 
be ignored by a receiver if that content is 'not understood' (see below for 
original post).

One aspect of this which troubled me slightly was how the communicating 
parties agree on what content can/should be ignored and what content 
can/should be retained. In some vocabularies a protocol agreement is made 
which can be asserted at run-time (e.g. ebXML CPA) but for many exchanges, 
that protocol agreement (particularly in a B2B scenario) may just be the 
subject of 'out of band' discussion/documentation and often-times will not 
cover this aspect specifically (or at least it may only come up some time 
after the original agreement was made).

For a while I have had a document called 'Open XML Markup Compatibility' 
(http://www.microsoft.com/whdc/xps/xmcompatspec.mspx) and today I gave it a 
read over. It's basically a specification which describes formal annotations 
that can be used to assert 'mustUnderstand',  'ignoreable' and preserve 
content' requirements for message exchanges. That all sounds good. But I am 
wondering whether anyone out there a) agrees that it *is* useful/necessary, 
b) is using it in anger (or something equivalent).

My original post had no responses but I'm not sure if that was because 
no-one is really all that bothered about this subject (for us it has some 
potential in our versioning strategy)  ?

Regards

Fraser.

==== original post - Must Ignore Unkown (retain/discard) - August 30 2006 
====

Many of you will be familiar with this term which is used to describe
an approach to processing XML instances containing allowable content
that MAY be ignored by a receiver if that content is 'not understood'.
'Not understood' is typically related to content in particular
locations (extension points) which is contained in a namespace that is
[foreign] to that of the 'main' schema[s] and which a receiver MAY
have no prior knowledge of. This is a common (ish) approach where a
schema 'owner' wants to allow users of that schema to add arbitrary
(or possibly constrained) content without causing existing
implementations to fail during instance validation (at least if they
are only using standard schema validation capabilities of mainstream
parsers).

David Orchard has written much on this subject (as have a few others)
and also describes 2 variants of the must ignore unknown pattern,
specifically, 'discard' and 'retain'. As I understand it, the former
means that unknown content can be both ignored and discarded (not
passed to upstream processing) without generating and error, and the
latter, that content may be ignored but should *not* be removed. It is
the 'discard' aspect which, when I was discussing the possible use of
this approach recently, that came under some challenge. I would be
interested in this forums view :-)

The, not unsurprising, challenge was/is this :-

in a situation where :-
- message data is captured by some application
- the basic content model for the transaction is defined by a standard
schema to which all participants agree to conform
- the standard schema allows for extensibility at various points so
long as these are defined in a foreign namespace.
- some of the data captured has been specified by only one provide of
the service and that provider has arranged with the application owner
to put that data in the appropriate extensibility area in an agreed
foreign namespace.
- the message (including all extension data) will be sent to *all*
potential service providers of which there may be many
- the service provider who requested the additional data wants to use
the standards based data model *not* create a completely private
schema for this transaction.

so ... what should receivers of the message who do *not* understand
the extension do ?

Are they likely to be obliged (possibly by legal, regulatory, audit,
.. requirements) to retain ALL data that a customer has agreed to send
(perhaps for non repudiation, DPA, or other reasons) regardless of
whether they intend to process it or not. And if so, does that make
it a practical non starter given that the size and content of 'unknown
data' requires them to provide an adequate (and equally unknown)
storage (and retrieval) capability  (at least for those business
transactions to which these sort of obligations might apply) ???

Opinions welcome

Fraser

==== end of original post ====