Re: TAG input to EXI WG on Efficient XML Interchange and EXI Measurements

Dear TAG, EXI WG, and other friends,

it's been a long time and I've missed you. I hope you had fun at the  
TPAC which I unfortunately couldn't join.

In this message I speak solely for myself, and certainly not as a  
former representative or chair. It is merely that despite time and  
distance some questions still beriddle me, and Henry's post has  
brought them back to mind.

On Nov 29, 2007, at 20:34, Henry S. Thompson wrote:
> 1) Making the case for EXI
>
> On the face of it two propositions need to be confirmed in order for
> the proposed EXI Format to go ahead to REC:
>
>   1a) The proposed EXI format is the best available choice for the  
> job;
>   1b) The performance of the proposed EXI format makes it worth going
>       ahead.

I cannot help but wonder: how is this not the case for any technical  
report that intends to reach REC status? As a simple pedestrian by- 
stander, the first thing that comes to mind as I read these two  
points is "is the TAG saying that other W3C TRs that go ahead to REC  
are either not the best available choice for the job, not sufficient  
improvements on what precedes them, or worse: neither?"

On the other hand, if other RECs are indeed generally both the best  
choice and sufficient increments to justify their existence, what is  
it about this specific REC that requires the TAG to forcefully  
restate what after all seems like mere common sense?

> 2) Positioning EXI going forward
>
> The value of XML interoperability is enormous.  If EXI goes forward,
> it must do so in a way which does not compromise this.  The WG needs
> to take every opportunity to get the message across that EXI is
> primarily aimed at a set of core use-cases, where one-off binary
> formats and/or lower-performance generic compression techniques are
> already in use.  _No_ aspect of the public presentation of EXI should
> suggest that generic XML tools will or ought to evolve to read or
> produce the EXI format.
>
> If the EXI WG agrees with this perspective on positioning, that TAG
> will be happy to assist in any way it can to promote it.  If the EXI
> WG does _not_ agree, further discussion is needed urgently to try to
> find a position which both parties can agree to.

I cannot speak for either party, but if the above is to hold water  
then I urge you all to immediately find a more agreeable position!

First if not foremost, generic XML tools will and ought to evolve to  
read or produce whatever the heck their users or the itches of their  
creators want and wish. It is hardly the place of a TR or of the TAG  
to make any comment on that matter. It is true that in the past  
suggestions that a new technology should be made an integral part of  
the XML stack have turned out to be disastrous for interoperability  
(e.g. XML Schema), but by the same token there is no reason that  
suggesting that they shouldn't will have more positive effects. It  
would seem better to me to design for openness, interoperability, and  
independent invention, and let it all work or fail on its proverbial  
own merit rather than attempt to prescribe one way or another.

But more importantly there is a semi-transparent subtext in the above  
that EXI represents a threat to XML and its interoperability. That's  
easy to believe: technology is a complicated, brittle little thing,  
and if one has learnt from experience to be cautious then one knows  
in one's mind and heart that despite being one of the most stunning  
technological successes of the past decades, XML could still be under  
massive threat of near-annihilation from an up-and-coming W3C REC  
that at least twenty-seven people have heard about.

However, given the many threats that could endanger any given  
technology it would be helpful to know which ones the TAG fear most  
for XML from EXI. More precisely, since one is presumably dealing in  
issues not already present, what threats does EXI pose which are not  
already brought about aplenty by:

  a) JSON;
  b) XML 1.1;
  c) XML 1.* using encodings that are neither UTF-8 nor UTF-16;
  d) the XML 1.* disparities in processing between validating  
parsers, non-validating parsers, and non-validating that read the  
external subset (every seventh moon cycle);
  e) the encouragement of data models that seem to fit poorly with  
XML (e.g. RDF) and subsequent promotion of alternative formats;
  f) the encouragement of technologies that promote dropping XML's  
extensibility and/or promote strong typing notions to a processing  
pipeline that is expected to be properly textual (XML Schema, XSTL  
2.0, XQuery).

While I obviously can't speak for the EXI WG, I believe it would make  
its task much shorter and simpler if it didn't need to explain that  
it doesn't increase the already existing threats posed by, say, tea  
mugs held too close to keyboards or EMP attacks from lolcat haters.

Take care!

-- 
Robin Berjon - http://berjon.com/
------------------------------------------------------------------------
"How vulgar, this hankering after immortality, how vain, how false.
  Composers are merely scribblers of cave paintings. One writes music
  because winter is eternal and because if one didn't, the wolves and
  blizzards would be at one's throat all the sooner."
                         -- David Mitchell, Cloud Atlas

Received on Friday, 7 December 2007 17:11:48 UTC