Cart
[Home] [By Thread] [By Date] [Recent Entries]
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] |
