Re: [xml-dev] A question about the future of efficient XML

[noah_mendelsohn@us.ibm.com]

Ed Day writes:

> I think the point you are missing here is that an efficient XML
> interchange 
> technology is not intended to "replace" XML, it is intended to 
> "complement" 
> it.  It is an alternative interchange format for those use 
> cases that cannot 
> deal with bulkiness of XML in its current form.  In that 
> regard, it can be 
> seen as something that will expand XML's use into new areas.

Indeed, but there are compromises as well.  The community has settled 
pretty effectively on the serializations of XML that will interoperate 
over what I have to assume are at least 10's of millions, and probaby 
100's of millions of deployed pieces of software.  Almost surely, any 
format advertised as XML (of any sort) that is not readable by all those 
many millions of deployed tools, whether parsers embedded in verticle 
applications, general purpose tools like Excel or 1-2-3 spreadsheets, the 
many database systems that are XML-enabled, etc., will seriously 
compromise users' expectations that:   when someone hands me an XML file, 
all these tools can read it.   So, various proposals for binary XML are a 
tradeoff:  the potentially expand the range of applications that can be 
addressed by XML-family technologies, while compromising the expectation 
that any file labeled as XML (by which until we've meant "well-formed") 
will be parseable by any of these tools. 

As I say, it's a tradeoff.  I happen to think that the advantages Michael 
Kay has listed for text XML are compelling, except where the size or speed 
of some other form is absolutely essential.  There are indeed some 
important cases where binary is needed, IMO.  Speaking for myself, I'm not 
convinced that the requiements across such applications (I.e. office file 
formats, large databases that need compressed representations, large 
arrays or matrices of floating point scientific data, formats for use 
where networks are very slow relative to processors, formats for use where 
battery life of a mobile device is a concern, formats that do Web services 
efficiently, formats that compromise XML self-description by relying on 
pre-agreed schemas or dictionaries), are sufficiently common that one 
>standard< is a good way to meet them.  The EXI workgroup has the charter 
to explore that space, and it will be interesting to see what they finally 
come up with.

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








"Ed Day" <eday@obj-sys.com>
06/11/2007 09:32 AM
Please respond to "Ed Day"
 
        To:     "Michael Kay" <mike@saxonica.com>, "'Miroslav Hajda'" 
<bomi@centrum.cz>, <xml-dev@lists.xml.org>
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        Re: [xml-dev] A question about the future of 
efficient XML


Hi Michael,

I think the point you are missing here is that an efficient XML 
interchange 
technology is not intended to "replace" XML, it is intended to 
"complement" 
it.  It is an alternative interchange format for those use cases that 
cannot 
deal with bulkiness of XML in its current form.  In that regard, it can be 

seen as something that will expand XML's use into new areas.

Regards,

Ed Day
Objective Systems, Inc.
http://www.obj-sys.com


----- Original Message ----- 
From: "Michael Kay" <mike@saxonica.com>
To: "'Miroslav Hajda'" <bomi@centrum.cz>; <xml-dev@lists.xml.org>
Sent: Sunday, June 10, 2007 1:53 PM
Subject: RE: [xml-dev] A question about the future of efficient XML


> Predicting the future is always difficult, and I can't claim a good 
track
> record at it. However, one of the rules is that the more entrenched a
> technology is, the harder it is to displace it with something better.
> Remember the 3.5inch floppy? It disappeared in the end, but not until 
> there
> was a technology that was about 500 times better, and even then it took 
at
> least five years between obsolescence and extinction.
>
> And with textual vs binary XML, you don't just have to overcome inertia, 

> you
> have to overcome the fact that a textual format has very considerable
> advantages in terms of the ability of humans to read and edit the 
content
> directly. Look at the xsl-list - how many people would offer free advice 

> and
> help on debugging XSLT stylesheets if the source documents were supplied 

> in
> binary rather than textual form? Human performance is much more 
important
> than machine performance.
>
> Michael Kay
> http://www.saxonica.com/
>
>> -----Original Message-----
>> From: Miroslav Hajda [mailto:bomi@centrum.cz]
>> Sent: 10 June 2007 16:57
>> To: xml-dev@lists.xml.org
>> Subject: [xml-dev] A question about the future of efficient XML
>>
>> Hello,
>> this might be an inappropriate subject for this list, but I'm
>> one of those people who still believe in a binary solution
>> (not necessarily a binary/efficient XML). You know... Because
>> of performance, storage capabilities (see
>> http://xmlsucks.org) and I don't believe, that English is so
>> perfect, that it will be here forever, and with unchanged
>> meaning for tag names.
>>
>> Therefore I would like to ask how wide will be an efficient
>> XML used, like will it be just an alternative for special
>> cases (mentioned in the Binary XML Use Cases
>> http://www.w3.org/TR/xbc-use-cases/ ) or might it be possible
>> to use it as some "compression schema" for web browsers as
>> well or, in an extreme case, will it be used for all
>> documents and shift regular XML to be just a textual interface?
>>
>> Well, I like the XML as a textual interface, but I don't like
>> forcing data into it just because we can spare time on
>> programming special tools. I think that providing such tools
>> instead of using simple text editors will be worth gained
>> performance. I also think, that the XML have to be thrown
>> someday as the text will become obsolete, as for example with
>> a direct brain implants communication or whatever... It might
>> happen, right? :-)
>>
>> I personally prefer an opposite way than the XML
>> binarization. I would rather construct a reliable binary
>> format with XML-similar textual interface and hide it as a
>> sublayer. I did some work on my own alternative binary format
>> already. It is in a planning stage and it isn't even
>> completely translated yet: http://xbup.sf.net
>>
>> Best regards and sorry for my non-perfect English, HajdaM,
>> Czech Republic
>>
>>
>> ______________________________________________________________
>> _________
>>
>> 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: xml-dev-unsubscribe@lists.xml.org
>> subscribe: xml-dev-subscribe@lists.xml.org List archive:
>> http://lists.xml.org/archives/xml-dev/
>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>>
>
>
> _______________________________________________________________________
>
> 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: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
> 


_______________________________________________________________________

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: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php