XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] A simple and non-brittle way to create XML that evolves over time

A variant of this is the XSLT "forwards compatibility" policy where unknown elements and attributes are ignored if and only if the version number on the document instance is greater than the version number of the application/processor. The benefit of this is that you can combine the extensibility goal with the goal of detecting errors (e.g. misspelled element names)

Michael Kay
Saxonica
mike@saxonica.com
+44 (0) 118 946 5893




On 29 Apr 2015, at 14:39, Costello, Roger L. <costello@mitre.org> 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

 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS