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
_______________________________________________________________________
XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.
[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
