Cart
[Home] [By Thread] [By Date] [Recent Entries]
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@p...> 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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
