[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Open XML Markup Compatibility

• From: "Dave Orchard" <orchard@p...>
• To: "'Fraser Goffin'" <goffinf@g...>,"'David Lyon'" <david.lyon@p...>, <xml-dev@l...>
• Date: Wed, 13 Sep 2006 11:36:33 -0700

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

• Follow-Ups:
  • Re: Open XML Markup Compatibility
    • From: "Fraser Goffin" <goffinf@g...>

• References:
  • Re: Open XML Markup Compatibility
    • From: "Fraser Goffin" <goffinf@g...>