RE: Another binary XML approach

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

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.  

<rant target="nonspecific">
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.

Len Bullard
Intergraph Public Safety
clbullar@ingr.com
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Stefan Zier [mailto:Stefan.Zier@syntion.com]
Sent: Wednesday, April 11, 2001 10:23 AM
To: Bullard, Claude L (Len)
Cc: xml-dev@lists.xml.org
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.

---------------------------------------
Stefan Zier
Software Developer
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)" <clbullar@ingr.com>
To: <xml-dev@lists.xml.org>
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
taking
>
> out cost.  It is amazing how we keep replicating the complexity and costs
of
> human
> communication using negotiating agents.
>
> Barrett:  "Right. All you have to do is write up an XSL style sheet,
install
> 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.
>
> Len
> http://www.mp3.com/LenBullard
>
> Ekam sat.h, Vipraah bahudhaa vadanti.
> Daamyata. Datta. Dayadhvam.h
>
>
> -----Original Message-----
> From: Stefan Zier [mailto:Stefan.Zier@syntion.com]
>
> http://www-106.ibm.com/developerworks/features/feat-transcoding.html
>
> They basically have a piece of software called "IBM WebSphere Transcoding
> Publisher" which - amongst other things - has the capability of
compressing
> XML for certain communication paths. I think this is geared towards the
app
> server and mobile markets, but has some advantages, one important one
being
> 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
be
> understood by the recipient device (e.g. it might strip some images or
tags
> not known by mobile devices).
>
> ------------------------------------------------------------------
> The xml-dev list is sponsored by XML.org, an initiative of OASIS
> <http://www.oasis-open.org>
>
> 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: xml-dev-request@lists.xml.org
>