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:] On Behalf Of G. Ken Holman
> Sent: Friday, May 01, 2015 5:25 PM
> To: Costello, Roger L.;
> Cc:
> 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: |
> 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:
> subscribe:
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
