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

["Costello, Roger L." <costello@mitre.org>]

Thanks a lot Ken. That makes good sense. So, "hasA" means containment/hierarchy/parent-child.

Okay, I'm confused. Walter says that JSON uses the "isA" view. Well, here is a valid JSON instance:

{
    "Book": 
        {
            "Title": "Parsing Techniques",
            "Authors": [ "Dick Grune", "Ceriel J.H. Jacobs" ],
            "Date": "2007",
            "Publisher": "Springer"
        }
}

That JSON appears to me to express containment/hierarchy/parent-child. Surely it is expressing this: 

	Book has a title "Parsing Techniques", with Authors Dick Grune 
	and Ceriel J.H. Jacobs, date (of publication) 2007, and publisher 
	Springer.

Isn't the JSON expressing a "hasA" view?

Walter, are you saying that the "hasA" view comes from something other than containment/hierarchy/parent-child?

/Roger

-----Original Message-----
From: G. Ken Holman [mailto:g.ken.holman@gmail.com] On Behalf Of G. Ken Holman
Sent: Friday, May 01, 2015 5:25 PM
To: Costello, Roger L.; xml-dev@lists.xml.org
Cc: wperry@fiduciary.com
Subject: Re: [xml-dev] RE: List of differences between XML and JSON?

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