From xml-dev Tue May 12 19:20:46 2015 From: Shaun McCance Date: Tue, 12 May 2015 19:20:46 +0000 To: xml-dev Subject: Re: [xml-dev] A simple and non-brittle way to create XML that evolves over time Message-Id: <1431458446.15468.192.camel () recto> X-MARC-Message: https://marc.info/?l=xml-dev&m=146143374203767 The "must ignore" policy is good for data-oriented formats. It's awful for text-oriented formats. In Mallard, we were very careful to define how unknown elements are handled. Mallard is designed to be extended, and it's important to have predictable fallback behavior. The behavior for unknown elements depends on the context. In Mallard, this is defined for three contexts: info, block, and inline. http://projectmallard.org/1.0/mal_info#processing http://projectmallard.org/1.0/mal_block#processing http://projectmallard.org/1.0/mal_inline#processing The fallback behavior for info content is the "must ignore" policy you describe. This is clearly the best behavior for any non-linear sets of data. The fallback behavior for inline content is to pass through, as if the entire element were replaced by its contents. If you don't do this, you end up with lost words. This is some text. GOOD: This is some text. BAD: This is . This is clearly the best behavior for inline content. Mallard's defined fallback behavior for block content is tricky, and isn't clearly always the best behavior. Basically, the contents of the unknown block are processed, much like the inline behavior. Except that unknown child elements in the unknown element are ignored. So, for example, it's possible to provide a fallback image for tools that don't support SVG embedded in Mallard: http://projectmallard.org/about/learn/svg#fallback And the conditional processing extension takes full advantage of this behavior to allow fairly sophisticated fallback behavior: http://projectmallard.org/if/1.0/fallback It does mean you have to craft your new elements or extensions to work well with this behavior. And one downside is that it's not possible to define a new general block element that takes inline content. It only works for new block container elements. But on the whole, it's worked well, and I'm happy with the design decision. -- Shaun On Wed, 2015-04-29 at 13:39 +0000, Costello, Roger L. wrote: > Hi Folks, > > > > Acknowledgement: Some of the below text and idea comes from section > 4.2 of RFC 7493 (http://www.rfc-editor.org/rfc/rfc7493.txt) > > > > It is frequently the case that changes to XML Schemas are required > after they have been put in production. XML Schemas that allow the > introduction of new elements in a way that does not disrupt the > operation of existing software have proven advantageous in practice. > > > > This can be referred to as a "Must-Ignore" policy, meaning that when > an implementation encounters an element that it does not recognize, it > should treat the rest of the document as if the new element simply did > not appear, and in particular, the implementation must not treat this > as an error condition. The converse "Must-Understand" policy does not > tolerate the introduction of new elements, and while this has proven > necessary in certain designs, in general it has been found to be > overly restrictive and brittle. > > > > A good way to support the use of Must-Ignore in XML designs is to > require that the root element must contain a list of key/value pairs > where each key is unique, and to specify that keys whose names are > unrecognized must be ignored. > > > > Example. Here is an XML document where the root element contains a > list of key/value pairs and each key is unique: > > > > > The First and Last Freedom > J. Krishnamurti > 1954 > 0-06-064831-7 > Harper& Row > > > > > This example shows simple values for each key. Of course the values > could be complex. > > > > Suppose that at a later date the XML Schema is extended to include a > NumPages element. Now XML instances contain this: > > > > > The First and Last Freedom > J. Krishnamurti > 1954 > 289 > 0-06-064831-7 > Harper& Row > > > > > If a consumer of this XML has not been coded to understand that new > key/value pair, the consumer must ignore it. > > > > Recap: design your XML so that the root element contains a list of > key/value pairs where each key is unique. Notify consumers that over > time the set of root element keys will expand and they should ignore > any root element keys they do not understand. > > > > /Roger > > > > _______________________________________________________________________ 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@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php