[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Protocol Buffers - Why not use XML

• From: Peter Flynn <peter@silmaril.ie>
• To: xml-dev@lists.xml.org
• Date: Sat, 13 Feb 2016 21:58:03 +0000

On 02/13/2016 04:46 PM, Arjun Ray wrote:
> On Mon, 08 Feb 2016 20:52:36 -0500, Ihe Onwuka <ihe.onwuka@gmail.com>
> wrote:
> 
> | Can anybody express an informed opinion to the question in the subject
> | which was culled from the Protocol Buffer Google Developer Guide.
> | 
> | https://developers.google.com/protocol-buffers/docs/overview as the ones
> | written seem to have  an XML phobic slant.
> 
> I'm not sure "XML phobic" is accurate, although the authors do go
> wrong in characterizing XML as a "mechanism for serializing structured
> data", which is precisely where all the bad karma originates.  That
> is, if the question is "a flexible, efficient, automated mechanism for
> serializing structured data", then just about all of the time XML is
> _not_ the answer. 

The problem is, there are far too many poorly-informed people
promulgating the view that XML is exactly that "mechanism for
serializing structured data". Liam, as usual, puts his finger on it:
"Our sweet spot was and remains encoding, archiving, interchange &
processing of complex documents". We have just not been very good about
making that clear; in my field, largely because programmers glaze over
when you talk about XML and documents.

> Phobia has nothing to do with it. On the contrary, far too many almost
> instantly sclerotic systems - manifesting Erik Naggum's "When the
> markup overhead exceeds 200%, when attributes values and element
> contents compete for the information, when the distance between 99% of
> the 'tags' is /zero/" - have already been built on faddish beliefs in
> the imagined benefits of XML.  

On the other hand, I have documents exactly like this, with a markup
payload of 500% of the document text and more, precisely because it adds
value to the documents for their users far exceeding any minor
inconveniences of pointy brackets getting in the way. No prizes for
guessing that this is formal document encoding of historical and
literary texts in TEI.

> Protobufs haven't swept the field, though.  There are AVRO, Thrift,
> and others, making for interesting choices.  All of them are purpose
> built for the problem domain - serialization of structured data - and
> should be obviously prefered.
> 
> But how about marking up documents - where free flowing text and
> annotations are the rule - with protobufs or any of the others?  

Someone showed a [literary] TEI document converted from XML to JSON a
couple of years ago at the XML Summer School, I think. Interesting but
not useful.

///Peter

• Follow-Ups:
  • Re: Protocol Buffers - Why not use XML
    • From: Arjun Ray <arjun.ray@verizon.net>

• References:
  • Protocol Buffers - Why not use XML
    • From: Ihe Onwuka <ihe.onwuka@gmail.com>
  • Re: Protocol Buffers - Why not use XML
    • From: Arjun Ray <arjun.ray@verizon.net>