XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [ubl-dev] Top 10 uses of XML in 2007

Hi David

I agree that when we are doing B2B then there may be in many cases
compression already. In non-B2B though, such as within an
organisation network or intranet, I would see binary XML as becoming
commonplace to increase performance. Then, if you standardise that
and the standards for binary XML are widely adopted, what would there
be to stop those same binary formats being used between businesses
such as over the Internet. Just a natural progression, it seems to me,
cutting costs by using the same thing everywhere and just dumping
the XML to text when appropriate to do so, such as where there is
a need for longterm persistence (several years) when there is the
risk that there might not be applications available to read the binary
in later stages of data usefulness and when there is a similar requirement
to dump it to paper or microfilm say. First the binary needs to be made
of a ubiquitous standard much as ASCII is for text. After all most data
management happens now in binary databases rather than SQL text
and the latter, though it could be the primary format, is relegated just
to backup and archiving. Of course, ASN.1 can provide extra binary
compression by utilizing the benefits of a schema for the XML and that
could become the fashion if there is a known schema (one benefit of
having a schema after all besides mere validation and documentation).
Not sure how that would be for internal application integration though.
Maybe combine BPEL and fast infoset (or whatever takes its place)
then do the same with non-WSDL equivalent middleware and the like.

All the best

Stephen Green


On 15/02/07, David RR Webber (XML) <david@drrw.info> wrote:
> Stephen,
>
> This is a strong case of deja vu.
>
> Ten years ago (has it REALLY been that long already?!) - when we first
> advocated XML for EDI - the payload size was a major concern.  Back
> then dial-up modems were still the major connection means - and some
> large systems were sending 35MB of EDI transactions daily.  This all
> seems quaint now - where network connections provide 5MB per minute and
> faster downloads!!
>
> Back then however the solution was built-in already to the modems - the
> higher protocols automatically did ZIP compression on text traffic.
> Similarly now - most database and hard drive technology is
> automatically compressing content on storage.
>
> It seems to me that this is always going to be a tradeoff - how long
> does the compress/decompress take compared to the transmission times?
>
> Notice that in many eGovernment applications the XML component of the
> traffic is being tiny compared to the rest of the payload.
> Specifically - PDF documents as attachments, or JPG images - in support
> of e-filing applications - far outsize the XML - example - eGrant
> applications typically are 3 to 5 MB - but only 35K of that is XML.
>
> Seems to me the biggest use of binary today is therefore likely to be
> encrypted payloads - since the need to minimize physical payload sizes
> is diminished by network bandwidth. And encryption normally is
> 'on-the-wire' as with SSL. The extra complexity being negated by either
> the hardware already compressing things "on the wire" - or simply
> providing a negative impact on processing.  E.g. The shippers -
> UPS/FedEx/USPS et al - use an XML based format for calculating local
> tax on shipments - this is a huge high volume system - peak of 1,000
> transactions a second - but the XML is in plain text - because
> compression would be a problem.  Transaction sizes are 500 bytes - use
> of codes extensive - and small tagnames.
>
> There are exceptions - such as NASA's needs for satellite transmissions
> from deep space - but I think for general eBusiness - text rules -
> because the cost difference is simply not there for average
> transmissions - and the extra complexity not justified.
>
> So - overall I think binary payloads is more applicable to non-XML
> content - and the ability of ebXML to already handle binary attachments
> - more than covers this.
>
> Just my tuppence worth here.
>
> DW
>
> "The way to be is to do" - Confucius (551-472 B.C.)
>
>
>  -------- Original Message --------
> Subject: Re: [ubl-dev] Top 10 uses of XML in 2007
> From: "Stephen Green" <stephen.green@bristol.gov.uk>
> Date: Thu, February 15, 2007 11:22 am
> To: <ubl-dev@lists.oasis-open.org>, <xml-dev@lists.xml.org>
>
> "The vendors who really can't live with XML won't be able to stomach
> binary XML either."
>
> Not sure the point here is too sound though. Not every vendor "can't
> live with XML".
> What about those who've embraced XML and found a golden opportunity to
> add
> performance to make it comparable with other technologies and customer
> demands
> by adding the binary too. Maybe this prediction will be off the mark. I
> hope so. If
> everything (and that is a lot of things in ICT!) has to be text then we
> could have a
> big problem selling solutions to savvy customers. I don't see it really.
> People know that
> binary is usually necessary and more likely it is 'text only' which is
> the pipe dream.
> Look at office documents. They are XML, sure, but they are zipped and
> therefore a
> type of binary XML, and the customers probably wouldn't really have it
> any other way.
> Storage, rpc and messaging requirements are all very different and not
> all look good
> in text.
>
> All the best
>
> Stephen Green
>
>
> >>> "David RR Webber (XML)" <david@drrw.info> 14/02/07 18:09:51 >>>
> http://www-128.ibm.com/developerworks/xml/library/x-xml2007predictions.html
>
>
> Interesting round-up - I agree APP is of strong interest. RSS is the
> largest use of XML on the planet - so APP a natural next step.
>
> This aligns well with the new REST work we're starting for ebXML
> registry as well.
>
> Forms - XForms and AJAX clearly will converge in their methods if not
> their syntax.
>
> But look what the article says about WS-* - I hate to keep harping on
> this - but I'm seeing my prediction of how this will shape out:
>
> 1) DIY web services
> 2) ebXML
> 3) WS-*
>
> being confirmed here...
>
> DW
>
> "The way to be is to do" - Confucius (551-472 B.C.)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>
>
> ______________________________________________________________________
> Please note the new simpler name for our website:
> http://www.bristol.gov.uk
>
> Our email addresses have also changed - visit
> http://www.bristol.gov.uk/bigchange for further details.
>
> Sign-up for our email bulletin giving news, have-your-say  and event
> information at: http://www.bristol.gov.uk/newsdirect
>
>
>
>
> ______________________________________________________________________
> Please note the new simpler name for our website:
> http://www.bristol.gov.uk
>
> Our email addresses have also changed - visit
> http://www.bristol.gov.uk/bigchange for further details.
>
> Sign-up for our email bulletin giving news, have-your-say  and event
> information at: http://www.bristol.gov.uk/newsdirect
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS