Re: [xml-dev] RE: List of differences between XML and JSON?

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2015-05-01 21:01 +0000, Costello, Roger L. wrote:
> Ø  the syntax of XML enforces the "hasA" view
>
> Walter,
I'm not one to put words into Walter's mouth as I
defer to and have always looked up to his sage
thoughts, so what I say here is my own interpretation.

> what is it in the XML syntax that enforces the
> “hasA” view”? (Please be specific)
Is it not, simply, the hierarchy?

> If I were to design a new data format language,
> what would I put in the language to enforce the “hasA” view?
Elements that contain other elements.  If you
have only a document element and then a serial
list of children without grandchildren, then you
only have the one "hasA" relationship, but not at each branch of the tree.

However, the more hierarchy (branches) you
introduce, the more "hasA" relationships are being described.

> What’s the principle at work?
Containership.

> How did the XML founding fathers sneak that into
> the XML language? By design or by accident?
I suppose by design, choosing to preserve the
SGML concept of expressing hierarchy and containership.

> What is the advantage of the “hasA” view?
It is unambiguous.  Anyone gets to interpret
"isA" any way they wish, but in the syntax
(remember, that is what Walter said, it is the
syntax) the start and end tags contain ("hasA") their descendants.

> Is it something that one should strive for when
> designing a data format language? Or is it something that is to be avoided?
Simply use hierarchy where hierarchy makes sense.

For example, this invoice does not exploit "hasA":

 <invoice>
   <sellto-name>Joe</sellto-name>
   <sellto-surname>Bloggs</sellto-name>
   <sellto-street>123 Main St.</sellto-street>
   <sellto-city>Anytown</sellto-city>
   <buyfrom-name>Jane</buyfrom-name>
   <buyfrom-surname>Doe</buyfrom-name>
   <buyfrom-street>234 Fornt St.</buyfrom-street>
   <buyfrom-city>Othertown</buyfrom-city>
   ...
 </invoice>

... whereas this invoice does exploit "hasA":

 <invoice>
   <seller>
     <name>
       <given>Joe</given>
       <family>Bloggs</family>
     </name>
     <address>
       <street>123 Main St</street>
       <city>Anytown</city>
     </address>
   </seller>
   <buyer>
     <name>
       <given>Jane</given>
       <family>Doe</family>
     </name>
     <address>
       <street>234 Front St</street>
       <city>Othertown</city>
     </address>
   </buyer>
   ...
 </invoice>

The invoice "has a seller" and "has a
buyer".  Both the buyer and seller "has a name"
and "has an address".  Every name has two
components, every address has two
components.  This is inherent in the syntax as a representation of a tree.

This is what I believe Walter is
highlighting.  As always, I applaud his insight.

I hope this helps.

. . . . . . . . .  Ken


--
Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
Free 5-hour lecture:  http://www.CraneSoftwrights.com/links/video.htm |
Crane Softwrights Ltd.             http://www.CraneSoftwrights.com/x/ |
G. Ken Holman                    mailto:gkholman@CraneSoftwrights.com |
Google+ profile:       http://plus.google.com/+GKenHolman-Crane/about |
Legal business disclaimers:     http://www.CraneSoftwrights.com/legal |


---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com