Cart
[Home] [By Thread] [By Date] [Recent Entries]
David, > Whoever did this in 'may-ignore' stuff in the first place must have skipped > communications 101. a little more detail on my environment is clearly needed (sorry the original post was already quite long so I left it out). Our service consumers (typically high street brokers) bind to and call web services on an industry portal, an example is an insurance quotation service for a given product. The portal will forward the same message to one or more implementers of that service. All of the messages are defined to have an industry standard structure. Sometimes insurers do deals with some brokers to capture additional data and want to have that data carried within the standard message but explicitly 'called out', typically using a agreed namespace 'foreign' to the main transaction schema. When the message is received by a service provider that 'understands' the namespace, it may process it. When it is received by a service provider that does not recognise it, it may safely ignore that content without raising an error. This is all possible using xs:any at various points in the schema, that is, the message would still pass schema validation for a provider who has no interest in the actual content in the extension point. It also provides a mechanism for the standards body for minor non breaking versioning of standard schemata. 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) ? > Secondly, any part of anything *may* be ignored, but it is up to the > receiver to make that decision. Absolutely. I'm quite certain that most of us who implement services do not necessarily process every piece of data that is sent. > When you get told by the communicator to ignore this and not that, you tend > to think about just ignoring the whole jolly lot... because the message > becomes to conveluted, confusing and too much effort to understand. The assertion from the caller is that you MAY ignore some content IF you don't understand it WITHOUT this being considered as an error (ie. that content in effect represents relationships between SOME of the parties that receive it but not necessarily all). Its a way of having a more generic message as opposed to lots of individual point-2-point tightly coupled services. Not saying that approach is wrong, both have merit IMO. > Go back and check the setting of the <may_be_ignored_flag = 0> :-) Regards Fraser. On 13/09/06, David Lyon <david.lyon@p...> wrote: > > ----- Original Message ----- > From: "Fraser Goffin" <goffinf@h...> > To: <xml-dev@l...> > Sent: Tuesday, September 12, 2006 7:29 PM > Subject: Open XML Markup Compatibility > > > > 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). > > Whoever did this in 'may-ignore' stuff in the first place must have skipped > communications 101. > > Firstly, if it may be ignored, then why send it in the first place? > > Secondly, any part of anything *may* be ignored, but it is up to the > receiver to make that decision. > > When you get told by the communicator to ignore this and not that, you tend > to think about just ignoring the whole jolly lot... because the message > becomes to conveluted, confusing and too much effort to understand. > > > 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) ? > > Go back and check the setting of the <may_be_ignored_flag = 0> > > Regards > > David > > > _______________________________________________________________________ > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > to support XML implementation and development. To minimize > spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@l... > subscribe: xml-dev-subscribe@l... > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
