OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: The SAX2 standard ? (was SAX2 bugs -- please file!)

Nic writes:

"How are we going to make sure that all these specs and technologies keep
coherent with
each other ? How are we going to prevent XML from exploding into multiple
sub-specs, thus failing to reach the possibilities of XML as an unifying
data exchange system ?"


Lots of groups decide, different groups select, 
and depending on the tools you buy or build, 
it lands on your desk.  Make no mistake, it 
is up to you to make sure your customer gets 
what they pay for and need.  Exercise promise control.

It's just that regardless of who provides the 
spec or standard, there is no magic in any of these 
documents.  There is always the grunt task just like 
building a hash table of testing these pieces, 
testing the assemblies, and testing the tests 
themselves.   There are no guarantees from any 
of the organizations that you can use to take them 
to task that will recover your reputation or 
assessed damages.  Our world of technology is 
that flimsy.  

On the other hand, lots of eyes are looking, 
lots of hands are testing, and so far so good 
in the majority of things.  We sit here and hash 
the specs and changes so we will be aware of the 
unknowns.  The multiple groups in the long run 
are a good thing.  They guarantee a certain balance 
of effort and power.  Making one group responsible 
for all authoritative decisions has in every 
case I can remember from history been a very  
bad move.  Checks and balances are not a design 
that emerges from logic, but from human understanding, 
something computer science still has a long way 
to go to encode well.

Don't treat XML as a unifying standard.  Treat 
is as glue that binds things which if well-carved 
and fitted will usually hold up under most extremes, 
and if not, don't break because of the glue but 
because they are force-fitted and under pressure. 

That's all.   

SAX works because for the most part, David et al 
didn't set out to do something extraordinary or 
beyond the pale of what XML implies is possible. 
They crafted based on requirements they understood 
and applied solutions they knew would work.  For 
that reason, SAX will hold up with or without a 
formal group to support it.  What you may want to 
worry about is processes that sometimes have to 
as Blueberry is doing, reach right down to the 
fundamental assumptions and tweak.  In these 
cases, pay careful attention and don't declare 
a consensus unless you really have one.


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