[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XML design: don't use duplicate keys in XML objects

  • From: Hans-Juergen Rennau <hrennau@yahoo.de>
  • To: Michael Kay <mike@saxonica.com>, "Costello, Roger L." <costello@m...>
  • Date: Mon, 4 May 2015 21:41:18 +0000 (UTC)

Re:  XML design: don't use duplicate keys in XML objects
Michael wrote:
"The use of wrapper elements in XML in this way is highly debatable. One excellent reason for NOT using them is for schema evolution."

That is an interesting thought. On the other hand, we have a sense of structure and balance, which is satisfied by grouping, as the "weight" of information conveyed by "author(s)" - be they one, two or four - remains at a par with the "weight" of information conveyed by the title. Dare I propose an esthetic rule that child elements should (if possible) have comparable weight, and the weight is obviously rather uncoupled from the number of value items. Don't you feel that this example looks "unstructured" and painful to read:
<a>
   <b>...
   <c>...
   <c>...
   <c>...
   <d>...
</a>

while this looks more mind-friendly:
<a>
   <b>
   <cs>
      <c/>
      <c/>
      <c/>
   </cs>
   <d>
</a>

Therefore I suggest the following schema style guideline: by default, do wrap multiple items by a plural item; consider omitting the wrapper if (a) the occurrence of multiple values is rather exceptional, (b) the typical number of multiple items is small (<= 3).

I feel schema design is somewhat similar to writing prose - structures/sentences express information, and we must search for the structures/sentences which express it as naturally as possible (whatever this may mean). Good schema writing requires a particular kind of Sprachgefühl.

Hans-Juergen
 



Michael Kay <mike@saxonica.com> schrieb am 16:40 Donnerstag, 30.April 2015:


Describing this as a "duplicate key" seems very strange. It's a repeated property.

XML is not JSON, and good practice for JSON doesn't automatically translate to good practice for XML.

The use of wrapper elements in XML in this way is highly debatable. One excellent reason for NOT using them is for schema evolution. If you suddenly find that a book can have more than one ISBN, then it is less disruptive to existing applications to add a second child ISBN element than to add a wrapper around all the ISBNs. In fact it's a particular strength of XML that it allows this. XML works very well with properties that usually occur once but occasionally more often, because the "one" case extends naturally to the "more than one" without requiring a redesign.

Michael Kay
Saxonica
+44 (0) 118 946 5893




On 30 Apr 2015, at 14:30, Costello, Roger L. <costello@mitre.org> wrote:

Hi Folks,
 
An XML object is an element whose content is a collection of heterogeneous data items. For example, this Book element contains a collection of heterogeneous data items and therefore is an XML object:
 
<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>
 
The fact that it is an object becomes more apparent with this graphic:
<image002.png>
 
Recommendation: Don’t create XML objects with duplicate keys. For example, this Book object has duplicate Author keys:
 
<Book>
   
<Title>Parsing Techniques</Title>
   
<Author>Dick Grune</Author>
   
<Author>Ceriel Jacobs</Author>
   
<Date>2007</Date>
   
<ISBN>978-0387202488</ISBN>
   
<Publisher>Springer</Publisher>
</Book>
 
<image004.jpg>
 
Instead, create a single Authors element whose content is an array:
 
<Book>
   
<Title>Parsing Techniques</Title>
   
<Authors><Author>Dick Grune</Author><Author>Ceriel Jacobs</Author></Authors>
   
<Date>2007</Date>
   
<ISBN>978-0387202488</ISBN>
   
<Publisher>Springer</Publisher>
</Book>
 
Now the Book object contains a collection of unique keys. The value of the Authors key is an array of Author elements.
 
Why follow this recommendation? Here’s why:
 
1. It enables XML objects to evolve, using the Must-Ignore policy, as I described in yesterday’s message.
 
2. It enables conversion between XML and programming language objects and databases.
 
3. It is consistent with rfc 7493 (http://www.rfc-editor.org/rfc/rfc7493.txt) which recommends that no JSON object have duplicate keys.
 
/Roger
 





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


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.