[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Another binary XML approach
- From: "Bullard, Claude L (Len)" <firstname.lastname@example.org>
- To: Stefan Zier <Stefan.Zier@syntion.com>
- Date: Wed, 11 Apr 2001 10:42:21 -0500
As I recall, WAP servers convert to WML, preclude
XML validation on the client, make very little use
of WMLScript (so it is said) and do little form entry
validation. So this is a client that needs all the
help it can get and the binary already fielded,
tested, and proven effective is serving that client.
As to transform for device independence, for sure,
but that is XSLT in a nutshell. Intermediaries seem
to be proxies with another name. I don't know enough
about what IBM has done from that article. Objects
offering services to other objects doesn't sound
like a "world changing" idea. Call me sceptical
but glad to be proven wrong on that one. HumanML
processors could work like that too. What I read
in that article makes sense from the perspective
of value-added processing. I only note that
"middle man" exacts a cost for the service. Caveat emptor.
GZIP is in use and so far so good. IE clients also
zip now for the network. I've nothing on high transaction
systems so someone with some experience there should
comment. On the other hand, MS, Oracle do a lot of
that and I don't see their representatives asking for
this in this thread. In other words, if we argue from
"common experience", the argument tends in the other
direction. I'm not saying binaries won't be helpful;
just that so far the amount of help has yet to justify
the "standardization of a common XML binary". It has
justified language specific binaries.
Simple solutions are easy to find. The right solution
may not be. It may be the case that given costs
"no size fits all" so the right solution is status quo.
As others have pointed out, the requirement for a binary
needs some empirical evidence to back it up before one
considers specing the system. Some infrastructure needs
fielding experience before one even considers going
to a "large organization" for authoritative justification.
The IETF has a better approach for this. Spec/Develop/Field.
Is is worthy? Adopt.
Too often, waaaaay too often these days, people are justifying
pet projects as open standards efforts when in effect, a small
focused group should be creating a product, fielding it, and whomping
on the competition "Standardize before productize" is the
worst kind of colonization: "For queen and county and the
natives have to accept our imperialism because we are the
good guys." meanwhile, file patents, push out early and buggy
implementations, make them eat the costs of our mistakes.
It costs a lot to tear mistakes out of contracts.</rant>
Nyet. Sean is right. Prove it first.
Intergraph Public Safety
Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h
From: Stefan Zier [mailto:Stefan.Zier@syntion.com]
Sent: Wednesday, April 11, 2001 10:23 AM
To: Bullard, Claude L (Len)
Subject: Re: Another binary XML approach
I wasn't saying that every XML applications should have a man in the middle,
but as WAP shows, there are applications in which it does make a lot of
sense. In my opinion it would make sense to agree on a standard binary
encoding to avoid reinventing the wheel for each one of these applications.
Unfortunately, most generic compression algorithms such as the
dictionary-based one used by gzip are not suitable for embedded devices like
mobile appliances and cell phones due to their fairly high resource
consumption (memory and CPU cycles). Also, they're too costly to be applied
to high-volume transactional applications.
This is just a guess, but I think that a significant simplification and
improvement in efficiency (both im compression ratio and resource
consumption) could be achieved by an XML-specific compression scheme over
generic schemes such as gzip. However, it needs careful design - remember,
the simple yet suitable solutions are the most difficult ones to find.
Syntion AG - http://www.syntion.com
Leonrodplatz 2 - 80636 Munich/Germany
Phone +49 89 52 30 45-0
Fax +49 89 52 30 45-20
----- Original Message -----
From: "Bullard, Claude L (Len)" <email@example.com>
Sent: Wednesday, April 11, 2001 4:04 PM
Subject: RE: Another binary XML approach
> It is an interesting read, but it seems that adding "middle men" back into
> transactions has a way of defeating the thrusts of simplification and
> out cost. It is amazing how we keep replicating the complexity and costs
> communication using negotiating agents.
> Barrett: "Right. All you have to do is write up an XSL style sheet,
> it, and then set the configuration for when it should be used. Or you can
> alter somebody else's style sheet practically knowing nothing, although it
> is a fairly complex language. It's not for the faint of heart. I'd rather
> program Java any day."
> "Simple" is a familiarity index.
> Ekam sat.h, Vipraah bahudhaa vadanti.
> Daamyata. Datta. Dayadhvam.h
> -----Original Message-----
> From: Stefan Zier [mailto:Stefan.Zier@syntion.com]
> They basically have a piece of software called "IBM WebSphere Transcoding
> Publisher" which - amongst other things - has the capability of
> XML for certain communication paths. I think this is geared towards the
> server and mobile markets, but has some advantages, one important one
> that on both endpoints of communication data is still good old
> human-readable XML. One cool thing about it is that it can also do lossy
> compression (if you will) - it reduces a document to some subset that can
> understood by the recipient device (e.g. it might strip some images or
> not known by mobile devices).
> The xml-dev list is sponsored by XML.org, an initiative of OASIS
> The list archives are at http://lists.xml.org/archives/xml-dev/
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: firstname.lastname@example.org