Re: [xml-dev] A simple and non-brittle way to create XML thatevolves ove

[Shaun McCance <shaunm@gnome.org>]

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 <newelement>some text</newelement>.
  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:
> 
>  
> 
> <Book>
>     <Title>The First and Last Freedom</Title>
>     <Author>J. Krishnamurti</Author>
>     <Date>1954</Date>
>     <ISBN>0-06-064831-7</ISBN>
>     <Publisher>Harper&amp; Row</Publisher>
> </Book>
> 
>  
> 
> 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:
> 
>  
> 
> <Book>
>     <Title>The First and Last Freedom</Title>
>     <Author>J. Krishnamurti</Author>
>     <Date>1954</Date>
>     <NumPages>289</NumPages>
>     <ISBN>0-06-064831-7</ISBN>
>     <Publisher>Harper&amp; Row</Publisher>
> </Book>
> 
>  
> 
> 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
> 
>  
> 
>