Cart
[Home] [By Thread] [By Date] [Recent Entries]
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@s...> 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. 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 & 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] |
