Subject: [domainrep] REPUTEing with JSON

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 5 Mar 2012 23:27:24 +0000

Hi all,

Hoping it would reveal some interesting issues for to continue the whole XML vs. JSON discussion, I recently converted my REPUTE implementation from XML to JSON.

Unfortunately for the discussion, I hit no major snags.  Both client and server conversion took me an evening.  The payload in both cases for a simple REPUTE query is pretty small, though a little smaller in JSON.  The code after conversion is also a little simpler, but it could be argued that that's a function of the libraries I used to decode the payload and not of the formats themselves.  So, to me, there's not a clear winner.  But that does leave me partial to JSON because the API I chose (jansson) leaves my application code cleaner.

I am no expert in this area, so I have a question about schemas.  I hear about the idea of an XML schema a lot more than I hear one about a JSON schema.  Is it the case that, in XML, one would typically run an XML document against a schema to see if it matches before trying to extract values from it?  Or is that optional?  What about with JSON?

If there's a web page someone can point me to that makes a comprehensive comparison of the two, that might be very helpful for us here (and, actually, in WEIRDS too).

-MSK

---

From: "John Levine" <[email-masked]>
Date: 6 Mar 2012 01:15:23 -0000

>I am no expert in this area, so I have a question about schemas.  I hear about the idea of an XML schema a lot
>more than I hear one about a JSON schema.  Is it the case that, in XML, one would typically run an XML document
>against a schema to see if it matches before trying to extract values from it?  Or is that optional?  What about
>with JSON?

In production, it's more likely that you would use the schema as a
configuration file to tools that process the XML.  In my experience,
if you already know what the schema is, having a separate schema file
isn't very helpful.

R's,
John

---

From: "David F. Skoll" <[email-masked]>
Date: Mon, 5 Mar 2012 20:26:45 -0500

On Mon, 5 Mar 2012 23:27:24 +0000
"Murray S. Kucherawy" <[email-masked]> wrote:

> Hoping it would reveal some interesting issues for to continue the
> whole XML vs. JSON discussion, I recently converted my REPUTE
> implementation from XML to JSON.

It looks like a religious issue.  Googling "JSON vs XML" yields plenty
of religion.

I liked the comment at http://ajaxian.com/archives/json-vs-xml-the-debate:

"I believe that the most important thing to understand in the JSON and
XML debate is that they are really fundamentally built for two
distinct purposes. XML is built for giving semantic meaning two [sic] text
within documents. JSON is built for data structures."

I think REPUTE is exchanging data structures rather than text
documents with semantic meaning and I find JSON easier to read than
XML, so I'm mildly in favour of JSON.  Human readability of the
wire protocol is not required, of course, but if we are going to
make it verbose by using something like XML, we might as well
make it more human readable (and compact as a bonus.)

Regards,

David.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 6 Mar 2012 05:14:12 +0000

> -----Original Message-----
> From: John Levine [mailto:[email-masked]]
> Sent: Monday, March 05, 2012 5:15 PM
> To: [email-masked]
> Cc: Murray S. Kucherawy
> Subject: Re: [domainrep] REPUTEing with JSON
> 
> >I am no expert in this area, so I have a question about schemas.  I
> >hear about the idea of an XML schema a lot more than I hear one about a
> >JSON schema.  Is it the case that, in XML, one would typically run an
> >XML document against a schema to see if it matches before trying to
> extract values from it?  Or is that optional?  What about with JSON?
> 
> configuration file to tools that process the XML.  In my experience, if
> you already know what the schema is, having a separate schema file
> isn't very helpful.

I guess what I'm envisioning is an API to which you hand the input document and a schema.  The API checks the input against the schema and immediately throws an exception if it's non-compliant, otherwise it hands you the decoded document in some form that you can access without having to parse it yourself (e.g., accessor functions and the like).

It sounds like what you're saying is that user tools and such things that need to be pliable tend to have such capabilities, but nuts-and-bolts components like mail filters that are fairly rigid tend to do the schema enforcement piece on their own.  Is that about right?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 6 Mar 2012 05:18:29 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of David F. Skoll
> Sent: Monday, March 05, 2012 5:27 PM
> Cc: [email-masked]
> XML debate is that they are really fundamentally built for two distinct
> purposes. XML is built for giving semantic meaning two [sic] text
> I think REPUTE is exchanging data structures rather than text documents
> with semantic meaning and I find JSON easier to read than XML, so I'm
> mildly in favour of JSON.  Human readability of the wire protocol is
> not required, of course, but if we are going to make it verbose by
> using something like XML, we might as well make it more human readable
> (and compact as a bonus.)

I think my current leaning is that way too, but (as you can tell) that's not based on lengthy expertise in or experience of either one.  Over in WEIRDS we had a lot of discussion about baggage (namespaces?) that XML drags with it that sounded onerous, but I also haven't run into it in this work yet so maybe it's not so much of an issue for us.

But really, I'm currently fine with either.  For simple one-shot queries there's some space savings and readability gains with JSON over XML, but it's not such a huge burden either.  The jansson API seems a little cleaner than libxml2, but those are just the two I happened to pick.

I don't want to push for JSON merely because it's the current hotness, however.  But if it wins for other reasons, I'm in.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 6 Mar 2012 06:04:27 -0000

> It sounds like what you're saying is that user tools and such things
> that need to be pliable tend to have such capabilities, but
> nuts-and-bolts components like mail filters that are fairly rigid tend
> tend to do the schema enforcement piece on their own.  Is that about right?

I think so.  If you take a look at my little DMARC report parser, it
uses the perl module XML::Simple to slurp the entire XML into a tree
of perl hashes and arrays.  Since all XML fields have names, I can
write expressions like $xml{'report_metadata'}->{'org_name'} to pick
out a field at a specific place in the tree.  

That can get a bit piggy if you're parsing something big (although in
an era when laptops have 4G of RAM, piggy is more a state of mind) so the
usual approach is to register callbacks with your parser that fire when
it parses particular tags, but that still isn't using a schema.

Schemas are a lot more useful for syntax checking as you're creating
the XML, such as in an XML editor like xxe.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 6 Mar 2012 06:08:27 +0000

> Sent: Monday, March 05, 2012 10:04 PM
> To: [email-masked]
> Cc: Murray S. Kucherawy
> uses the perl module XML::Simple to slurp the entire XML into a tree of
> perl hashes and arrays.  Since all XML fields have names, I can write
> expressions like $xml{'report_metadata'}->{'org_name'} to pick out a
> field at a specific place in the tree.

Yeah, that's what libxml2 does as well, though with the obvious C constraints.  jansson is the same though you don't have direct access to the data structures but rather are forced to use accessor functions, which I think I prefer to crawling a data structure on my own.

Thanks for the insight.

-MSK

---

From: Steve Allam <[email-masked]>
Date: Tue, 06 Mar 2012 08:11:36 +0000

> the XML, such as in an XML editor like xxe.
I'll second that - we use a schema file to validate an xml config file 
after upgrades, in case the upgrade did anything strange (it might be 
merging fields) and have a validate tool available in case users 
directly edit the config file and want to check it (using the schema).

However, for the xml that gets passed back by out reputation query 
engine, we only have a schema to document the possibilities - it isn't 
used by the query engine that creates the xml, or used by the consumer 
(the connector that receives the answer) - although of course someone 
could write a consumer that checks it - the problem here is that when 
you are doing possibly thousands of queries per second, the overhead of 
checking the data structure is too high.  Thus, between two machine 
tasks, the schema is essentially fixed and trusted.

Note that our engine allows the querier to choose which output format it 
receives - either text (less data, proprietary format), HTML - in fact 
simply uses the HTTP result code to give a 'yes' or 'no', or XML - data 
+ extra information.

In theory, we could add a JSON option too.

Personally, I hate XML because cpan installs too many packages to enable 
simple parsing of a text file for my liking (this really from my earlier 
work in embedded systems where each kb was valuable) - however, it does 
a job and its easily scanned by a human, for debugging.

JSON we use also, to format internal message queue messages.  In some 
way, we have used each depending on which interfaces the tools support.  
However, we chose XML for the result format for the human readability 
for debugging (Not saying you can't read JSON, but I guess its the 
difference between reading SMS speak and email..)

Have you thought of allowing the engines to offer answers in both, and 
allowing the consumer to choose which type it wants (and thus also 
allowing the engine to state which it supports?)

Regards,

Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 6 Mar 2012 08:35:13 +0000

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Steve Allam
> Sent: Tuesday, March 06, 2012 12:12 AM
> To: [email-masked]

Hi Steve,

> tasks, the schema is essentially fixed and trusted.

Sounds like I shouldn't worry about schemas (schemae?) for either system.

> Note that our engine allows the querier to choose which output format
> it receives - either text (less data, proprietary format), HTML - in
> fact simply uses the HTTP result code to give a 'yes' or 'no', or XML - data
> + extra information.
> 
> [...]

My own current implementation supports both; you configure the client at compile time by picking which libraries to use, and configure the server at run time with a flag, because the output is just a bunch of "print" statements, i.e., generated manually rather than through an API, because the payload is so simple.

For standardization though, I fully expect we'll need to pick one and go with it, which is why we're debating the merits of these two.  Mind you, the working group could eventually decide it does want to have a JSON version and an XML version, though I expect we will eventually pick one, and it sounds like JSON has a slight edge at the moment.

Cheers,
-MSK

---

From: Dave Crocker <[email-masked]>
Date: Tue, 06 Mar 2012 05:37:16 -0800

On 3/6/2012 12:11 AM, Steve Allam wrote:
> Have you thought of allowing the engines to offer answers in both, and allowing
> the consumer to choose which type it wants (and thus also allowing the engine to
> state which it supports?)

please don't do that.  we aren't the ITU.

keep the based simple.  alternatives for the same thing aren't simple.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Don Owens (doowens)" <[email-masked]>
Date: Wed, 7 Mar 2012 02:06:15 +0000

+1 for JSON.

It is indeed a bit of a religious issue.  But I have found JSON much easier to deal with when working with data rather than documentation, and it's well-suited the "golden data structure" (nested arrays and maps).

./don

On Mar 5, 2012, at 5:26 PM, David F. Skoll wrote:

> _______________________________________________
> domainrep mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/domainrep

---

From: Leif Johansson <[email-masked]>
Date: Mon, 12 Mar 2012 16:43:38 +0100

fortunately for the discussion, I hit no major snags.  Both client and
> server conversion took me an evening.  The payload in both cases
> for a simple REPUTE query is pretty small, though a little smaller
> in JSON. The code after conversion is also a little simpler, but it
> could be argued that that?s a function of the libraries I used to
> decode the payload and not of the formats themselves.  So, to me,
> there?s not a clear winner.  But that does leave me partial to JSON
> because the API I chose (jansson) leaves my application code
> cleaner.

Your experience aligns well with other "testimony" from people who have
done similar things.

The thing to note is probably that you _could_ have written your code
from scratch without even using a library for JSON and had a reasonable
chance of getting it right. The same could not be said for XML probably.

	Cheers Leif