[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: Rick Jelliffe <rjelliffe () allette ! com ! au>
Date: 2013-03-25 2:55:17
Message-ID: CADUdYQVY4LNq_TpvVcOb3qCwS+_hovSXrXEYf7c_jiEzmBVOXg () mail ! gmail ! com
[Download RAW message or body]
Simon raises the good point that what is proposed is still markup. And is
open. Many of XMLs selling points were fair when comparing against binary
formats, ill-defined formats, secret proprietary formats, formats with so
much variability they cannot be parsed without extra metadata, but the
more that XML is compared with formats that are like XML (text, open,
neutral, well-defined, domain independent, generalized ) the less the clear
lead XML has. How could it be otherwise?
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!
Roger could add wiki formats and html5 syntax too. They all have sweet
spots. by the way, some CSV does allow subfields with a different
separator.
What Sgml tried to do was attempt to unify all these different kinds of
untyped markup. It made the simplest system too heavyweight. XML Schemas
tries to unify XML with typed markup, and again it is too heavyweight for
the kinds of tasks where JSON shines.
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.
Cheers
Rick
On Mar 25, 2013 11:19 AM, "Simon St.Laurent" <simonstl@simonstl.com> wrote:
> On 3/24/13 7:07 PM, David Lee wrote:
>
> > This thread is really getting really unintelligible to me but hey
> > that's why I subscribe. Its good to have my brain hurt. I will avoid
> > commentary on the most but I have 2 I can't help but reply.
> >
>
> xml-dev is an excellent place to get a headache, yes.
>
> 1) (Verbosity is the other common explanation.) <shameless plug> If
> > you truly buy into this, or don't ! ... I would love you to put your
> > 2 minutes where your mouth is and help establish some scientific
> > evidence. Please visit http://speedtest.xmlsh.org
> >
> > I will be having a public crow-eating party with the results. Not
> > sure who will be eating the crow so stay tuned. It could be me.
> > Please help humiliate me in public. Whatever it takes to get
> > volunteers !
> >
>
> It's not about processing or transmission speed - rather, it's about the
> overhead of those _things_ stuck in the data, things which often double or
> treble or quadruple or otherwise inflate the size.
>
> Sometimes it's typists complaining, but the more serious complaints were
> from people who simply had massive datasets and didn't want the overhead,
> whether that overhead was in (de)compressing them or in storing and
> transmitting them.
>
> I started out trying to convince them otherwise, but by the fifth or sixth
> conversation with people who not only disliked the markup but distrusted
> the standards organizations who had told them to use it, I stopped.
>
> They clearly had found better solutions in simpler text formats. It was
> still, in some sense, markup - it just didn't look anything like XML.
>
> Thanks,
> --
> Simon St.Laurent
> http://simonstl.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/<http://www.oasis-open.org/mlmanage/> Or \
> unsubscribe: \
> xml-dev-unsubscribe@lists.xml.**org<xml-dev-unsubscribe@lists.xml.org>
>
> subscribe: xml-dev-subscribe@lists.xml.**org<xml-dev-subscribe@lists.xml.org>
> List archive: http://lists.xml.org/archives/**xml-dev/<http://lists.xml.org/archives/xml-dev/>
> List Guidelines: http://www.oasis-open.org/**maillists/guidelines.php<http://www.oasis-open.org/maillists/guidelines.php>
>
>
[Attachment #3 (text/html)]
<p>Simon raises the good point that what is proposed is still markup. And is open. \
Many of XMLs selling points were fair when comparing against binary formats, \
ill-defined formats, secret proprietary formats, formats with so much variability \
they cannot be parsed without extra metadata, but the more that XML is compared with \
formats that are like XML (text, open, neutral, well-defined, domain independent, \
generalized ) the less the clear lead XML has. How could it be otherwise?</p>
<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's tool for overcoming problem X! </p>
<p>Roger could add wiki formats and html5 syntax too. They all have sweet spots. by \
the way, some CSV does allow subfields with a different separator. </p> <p>What Sgml \
tried to do was attempt to unify all these different kinds of untyped markup. It made \
the simplest system too heavyweight. XML Schemas tries to unify XML with typed \
markup, and again it is too heavyweight for the kinds of tasks where JSON shines. \
</p>
<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>
<p>Cheers<br>
Rick <br><br><br><br><br></p>
<div class="gmail_quote">On Mar 25, 2013 11:19 AM, "Simon St.Laurent" \
<<a href="mailto:simonstl@simonstl.com">simonstl@simonstl.com</a>> wrote:<br \
type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> On 3/24/13 7:07 PM, David Lee \
wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"> This thread is really getting really unintelligible to \
me but hey<br> that's why I subscribe. Its good to have my brain hurt. I will \
avoid<br> commentary on the most but I have 2 I can't help but reply.<br>
</blockquote>
<br>
xml-dev is an excellent place to get a headache, yes.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> 1) (Verbosity is the other common explanation.) \
<shameless plug> If<br> you truly buy into this, or don't ! ... I would \
love you to put your<br> 2 minutes where your mouth is and help establish some \
scientific<br> evidence. Please visit <a href="http://speedtest.xmlsh.org" \
target="_blank">http://speedtest.xmlsh.org</a><br> <br>
I will be having a public crow-eating party with the results. Not<br>
sure who will be eating the crow so stay tuned. It could be me.<br>
Please help humiliate me in public. Whatever it takes to get<br>
volunteers !<br>
</blockquote>
<br>
It's not about processing or transmission speed - rather, it's about the \
overhead of those _things_ stuck in the data, things which often double or treble or \
quadruple or otherwise inflate the size.<br> <br>
Sometimes it's typists complaining, but the more serious complaints were from \
people who simply had massive datasets and didn't want the overhead, whether that \
overhead was in (de)compressing them or in storing and transmitting them.<br>
<br>
I started out trying to convince them otherwise, but by the fifth or sixth \
conversation with people who not only disliked the markup but distrusted the \
standards organizations who had told them to use it, I stopped.<br> <br>
They clearly had found better solutions in simpler text formats. It was still, in \
some sense, markup - it just didn't look anything like XML.<br> <br>
Thanks,<br>
-- <br>
Simon St.Laurent<br>
<a href="http://simonstl.com/" target="_blank">http://simonstl.com/</a><br>
<br>
______________________________<u></u>______________________________<u></u>___________<br>
<br>
XML-DEV is a publicly archived, unmoderated list hosted by OASIS<br>
to support XML implementation and development. To minimize<br>
spam in the archives, you must subscribe before posting.<br>
<br>
[Un]Subscribe/change address: <a href="http://www.oasis-open.org/mlmanage/" \
target="_blank">http://www.oasis-open.org/<u></u>mlmanage/</a><br> Or unsubscribe: <a \
href="mailto:xml-dev-unsubscribe@lists.xml.org" \
target="_blank">xml-dev-unsubscribe@lists.xml.<u></u>org</a><br>
subscribe: <a href="mailto:xml-dev-subscribe@lists.xml.org" \
target="_blank">xml-dev-subscribe@lists.xml.<u></u>org</a><br> List archive: <a \
href="http://lists.xml.org/archives/xml-dev/" \
target="_blank">http://lists.xml.org/archives/<u></u>xml-dev/</a><br> List \
Guidelines: <a href="http://www.oasis-open.org/maillists/guidelines.php" \
target="_blank">http://www.oasis-open.org/<u></u>maillists/guidelines.php</a><br> \
<br> </blockquote></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic