XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] RE: List of differences between XML and JSON?

But why are you confused, Roger?

> Walter says that JSON uses the "isA" view.

But he never says that this means total exclusion of "hasA" interpretations. "Primacy" that Walter mentions is a good cue, do follow it.

I find this thread very enlightening -- thanks to everyone involved!

Best regards,

Piotr

On 01/05/15 23:53, Costello, Roger L. wrote:
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



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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS