Re: [xml-dev] Open XML Markup Compatibility

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

Dave,

> I think you could have 2 flavours of mU in your app, the ignore and must
> retain, and the ignore and may retain.

Agreed.

> But, the question in my mind, is why would the sender want to force the
> receiver to fail if it can't retain but can ignore.

Well I guess this was part of the thrust of my original post some
weeks back. In some cases there can be a legal or regulatory
requirement that the message that is actually sent to an endpoint MUST
be reproducable, perhaps for business audit and/or non repudiation
purposes. So even though a receiver may not be interested in content
which is marked as 'ignorable', it is only ignorable from a processing
point of view (actually I believe you made this point in your
materials on this subject). One of the practical problems this might
give rise to is that the receiver is basically being required to store
data of arbitrary size, something which it may or may not be able to
do.

For many of our operational systems we don't have ownership of the
source code and in some cases can't really change the structure of the
data store, so we would have to create something supplementary and
correlate the two datasets. So, even if we aren't bothered about some
ignorable content we may have to error because we can't retain it. In
those cases where there isn't a requirement for retaining content we
can safely ignore and discard. This is partly what Ken Holman
describes in the UBL 2 validation model proposal (transform before
validate to 'strip off' ignorable content - he does also mention that
you may need to create an audit of the complete message in some
cases).

I suppose this could be an argumanet for *not* allowing this form of
extensibility, but I *do* see potential for it and don't want to throw
the baby out with the bath water. IMO we *have* to find some
accomodation in messaging schemata for representing private
relationships (as user defined extensions) and allow minor non
breaking change.

> I'll point out that I think another big reason to "retain" is to be able use
> the "extra stuff" in the future.

Yes. One of the thing that I find attractive about the ability to
include private extensions in public schema is that some of these can
be regarded as 'candidate' standards for possible inclusion in the
future  (I know this wasn't quite your point - I've read your stuff on
adding extra structure and agree with it - but we still need somewhere
to persist it !)

It is the perma 'versioning and extensibility' howto that I still
can't quite nail down despite the best efforts of people such as
yourself, Ken Holman, Tim Ewald, Dare and many others. All have [good]
ideas but none seem completely satisfactory.

In my case I am trying to assist both my own organisation and the UK
insurance industry standards body formulate some strategy in these
areas. At present no extensibility whatsoever is allowed and version
changes are to all intents and purposes all 'breaking'. I am convinced
we can improve this position but need to spell out every use case
detail.

Regards

Fraser.

On 13/09/06, Dave Orchard <orchard@pacificspirit.com> wrote:
> Hi Fraser,
>
> > One of the issues I have with this is that a receiver who
> > wants to ignore the additional content still needs to know
> > whether that content MUST be retained (for [say] legal non
> > repudiation) or can actually be discarded altogether, perhaps
> > by applying a transformation before processing (as per the
> > current UBL 2 proposal). I was thinking that maybe the
> > annotations might help to make this clearer in the absence of
> > something like an ebXML Collabortion Protocol Agreement (CPA) ?
> >
>
> I think you could have 2 flavours of mU in your app, the ignore and must
> retain, and the ignore and may retain.
>
> But, the question in my mind, is why would the sender want to force the
> receiver to fail if it can't retain but can ignore.  Seems to me that an app
> would generally try to retain information if reasonably possible.  The
> difference between the two is the fault behaviour if it can't retain.
>
> Having the 2 modes only makes sense if there are clients that are prepared
> to talk to receivers that can ignore the content AND only talk to receivers
> that will keep the content in some cases.
>
> I'll point out that I think another big reason to "retain" is to be able use
> the "extra stuff" in the future.  For example, a middle name is added but
> isn't known.  If it's stored in the db in some "extra" table, then a future
> version of the db + app could know about the middle name and do something
> useful, such as return it in a query.
>
> I'm not sure of the app, but I think those are a couple of the key points of
> interest.
>
> Cheers,
> Dave
>
>
>