[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xml-dev
Subject:    Re: [xml-dev] Four fine text-based data formats ... liberate yourself from one (silo) data format
From:       Uche Ogbuji <uche () ogbuji ! net>
Date:       2013-03-25 3:12:37
Message-ID: CAPJCua2ODbKJtDaU9pXro-QzL+Er3xRQ-X8rRZRvrpM6NrM2RQ () mail ! gmail ! com
[Download RAW message or body]

On Sun, Mar 24, 2013 at 8:55 PM, Rick Jelliffe <rjelliffe@allette.com.au>wrote:

> I disagree with Simons problems with schemas, at least i think there are
> simple ways to avoid some of the problems: in many recent projects i use
> simple highly generic dtds for vocabulary, id and parent  constraints plus
> schematron for others: but these dont trap me because at any time i can
> plonk in processing instructions. It does not hold water to say that XML
> has problem X if you simultaneously reject utilizing Xml's tool for
> overcoming problem X!
>

Yeah in my case, in my recent projects I've used an Examplotron-based
modeling system I wrote into my Amara software (in Python).  I almost never
have to bother with heavyweight schemata.


JSON might get too heavyweight too if you tried to add a layer on JSON to
> indicate the status of each data item -- which is what XML is all about: is
> this part of the main text flow?, is this info about that text?, is this
> metadata/attribute?, is this text for under_the_hood messages to humans?,
> is this text part of some hack?  That status information is useful for some
> applications (industrial publishing) but not as compelling as an organizing
> principle for ephemeral data exchange,IMHO.
>
> Every technology has tradeoffs and these change over time. JSON embodies
> some good software engineering qualities (reducing overworking) but not
> others (for archiving having no comment mechanism is surely a
> complication). XML has no tag omission which restricts what can workably
> produce it.
>

Yeah, JSON is rather painful to use in my experience, and I use it almost
every day. The lack of comments is a killer.  And using JSON makes you
really appreciate XML's enforced end tags.  I so often get lost in a
thicket of "]" and "}" and end up having to primitively count on my fingers
while squinting at cryptic error messages.  Some of its strict rules are
pretty awkward (quotes and commas).  Adding a quick layer for some sort of
adapted processing can be an enormous labor.  With XML you just slap in a
new element or even use a PI.  Of course these are largely problems when
you're editing JSON by hand.  Generating JSON from code is usually
straightforward enough.  But it's hard to avoid dealing with it by hand if
it lurks anywhere in the system.  For example, unit test cases should
properly be hand-crafted.  I do like wiki text, though.  I use that a lot.


-- 
Uche Ogbuji                       http://uche.ogbuji.net
Founding Partner, Zepheira        http://zepheira.com
http://wearekin.org
http://www.thenervousbreakdown.com/author/uogbuji/
http://copia.ogbuji.net
http://www.linkedin.com/in/ucheogbuji
http://twitter.com/uogbuji

[Attachment #3 (text/html)]

<div dir="ltr">On Sun, Mar 24, 2013 at 8:55 PM, Rick Jelliffe <span dir="ltr">&lt;<a \
href="mailto:rjelliffe@allette.com.au" \
target="_blank">rjelliffe@allette.com.au</a>&gt;</span> wrote:<br><div \
class="gmail_extra"><div class="gmail_quote"> <blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p>I disagree \
with Simons problems with schemas, at least i think there are simple ways to avoid \
some of the problems: in many recent projects i use simple highly generic dtds for \
vocabulary, id and parent  constraints plus schematron for others: but these dont \
trap me because at any time i can plonk in processing instructions. It does not hold \
water to say that XML has problem X if you simultaneously reject utilizing Xml&#39;s \
tool for overcoming problem X!<br> </p></blockquote><div style><br></div><div \
style>Yeah in my case, in my recent projects I&#39;ve used an Examplotron-based \
modeling system I wrote into my Amara software (in Python).  I almost never have to \
bother with heavyweight schemata.</div> <div><br></div><div><br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">

<p>JSON might get too heavyweight too if you tried to add a layer on JSON to indicate \
the status of each data item -- which is what XML is all about: is this part of the \
main text flow?, is this info about that text?, is this metadata/attribute?, is this \
text for under_the_hood messages to humans?, is this text part of some hack?  That \
status information is useful for some applications (industrial publishing) but not as \
compelling as an organizing principle for ephemeral data exchange,IMHO. </p>


<p>Every technology has tradeoffs and these change over time. JSON embodies some good \
software engineering qualities (reducing overworking) but not others (for archiving \
having no comment mechanism is surely a complication). XML has no tag omission which \
restricts what can workably produce it. </p> </blockquote><div><br></div><div \
style>Yeah, JSON is rather painful to use in my experience, and I use it almost every \
day. The lack of comments is a killer.  And using JSON makes you really appreciate \
XML&#39;s enforced end tags.  I so often get lost in a thicket of &quot;]&quot; and \
&quot;}&quot; and end up having to primitively count on my fingers while squinting at \
cryptic error messages.  Some of its strict rules are pretty awkward (quotes and \
commas).  Adding a quick layer for some sort of adapted processing can be an enormous \
labor.  With XML you just slap in a new element or even use a PI.  Of course these \
are largely problems when you&#39;re editing JSON by hand.  Generating JSON from code \
is usually straightforward enough.  But it&#39;s hard to avoid dealing with it by \
hand if it lurks anywhere in the system.  For example, unit test cases should \
properly be hand-crafted.  I do like wiki text, though.  I use that a lot.</div> \
</div><br clear="all"><div><br></div>-- <br>Uche Ogbuji                       <a \
href="http://uche.ogbuji.net" target="_blank">http://uche.ogbuji.net</a><br>Founding \
Partner, Zepheira        <a href="http://zepheira.com" \
target="_blank">http://zepheira.com</a><br> <a href="http://wearekin.org" \
target="_blank">http://wearekin.org</a><br><a \
href="http://www.thenervousbreakdown.com/author/uogbuji/" \
target="_blank">http://www.thenervousbreakdown.com/author/uogbuji/</a><br><a \
href="http://copia.ogbuji.net" target="_blank">http://copia.ogbuji.net</a><br> <a \
href="http://www.linkedin.com/in/ucheogbuji" \
target="_blank">http://www.linkedin.com/in/ucheogbuji</a><br><a \
href="http://twitter.com/uogbuji" target="_blank">http://twitter.com/uogbuji</a><br> \
</div></div>



[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic