Reducing the level of violence - XHTML

[Len Bullard]

Simon St.Laurent wrote:
Hi Simon:

Looks like everyone over here is having a fun season.

> Discussing W3C issues on the XML-dev list seems to produce some remarkable
> levels of firepower. 

Goodness.  These look a lot like some discussions on other lists. 
People 
are passionate about their tools and their languages.  

> Simon St.Laurent
> XML: A Primer (2nd Ed - September)
> Building XML Applications
> Inside XML DTDs: Scientific and Technical
> Sharing Bandwidth / Cookies

I feel as if I need to write a book so I will have something to 
put in my sig for techCreds.  But ....

Namespaces looked to me on the surface as the solution to 
a problem we had in SGML:  aggregates.  Forever it seems, 
the world of markup was dominated by extremelyComplicatedDTDs 
in order to stick it all under a root with inclusions and 
exclusions to do the nasty bits where the tree just wouldn't 
be... hierarchical.
  
As an author, I hated these DTDs.  As a system implementor, I hated
these DTDs. 
As a DTD designer who did not like to be told at every turn 
which element types were mine to define and which would be 
available when the CommitteeOfCompetitors finished their 
deliberations and published their results six months after 
their companies implemented them, I HATED THESE DTDs.

That is as much violence as I can commit today.  From other 
work that tries to apply XML:

1.  They aren't worrying about namespaces.  They are worrying 
about how to get components to work cross-platform.  (don't 
say java.  it just starts a different fight.)  They thought 
XML would help with software components.  So did I.  Wrong?

2.  They are criticizing the flatness of XML with respect to 
datatypes and frankly, wonder what XML buys them if anything. 
(syntax-unification is not something most grad programmers have accepted 
since the curly brackets defeated the round brackets and were then 
challenged by the pointy brackets.  Dr Seuss would be so proud.) 
Ummm.. the datatype spec?  Where is it?  Should I just go ahead 
and say, "screw it; let's get back to familiar ground and 
let Microsoft win"?  Seems like the choices aren't mine to make 
because given the draggggggggggin feet, that is the only good 
game for meat and potatoes developers, eg, no deep science; just 
code it test it, field it, mod it. Get the Check. 

3.  The inability to reconcile the definition of what markup 
does and doesn't with respect to semantics seems to frustrate 
almost anyone who ever designed an interoperable system. (don't 
say framework, it just starts another fight.)  We can tell them 
that semantics are something only applications define and we 
will be right.  That leads them back to #2 and arguments about 
if the DOM is good for anything when you need real time performance 
given that they all know how to write a parser.  (the
desperatePerlHacker 
is a myth it seems.  They aren't desperate.  They are contentious.)

I was hoping that namespaces would indeed provide the indirection 
to code, be it classes, perl, or script.   Even if only by winking 
and nudging, it seems appropriate that XML have a means to do 
what other languages do so easily:  use a URL to point to SOMETHING.
 
It seems XML just can't make up its mind what it is good for in 
that respect.  Instead of cleaning up the touted mess of SGML, 
it seems to be replacing it.  OK.  The problems really are tougher 
than admitted.  OTOH, no relational programmer has any 
problem at all creating views which are aggregates from SQL 
statements that use unambiguous names for table resources.  They do 
consider that OUTPUT and do specify a lot of rules for naming 
and getting pieces of the recordset.   As a result, in this 
part of my career, building dynamic document databases is trivial.  
A memo field is a wonderful thing if combined with a standard 
set of markup object-handlers.  I like IE5 with data islands, 
XSL stylesheets, DOM scripts.  Tasty! 
 
Hybrid systems are good.  Store it in an optimized relational system, 
schlep out the text into whatever form the next handler wants, then 
play it.   Neat! Neat! More of that! 

As for the W3C processes, they turned the heat on themselves when 
they closed discussions to the public.  It was inevitable given 
the origins and myths that surrounded its founders.  As the twig 
is bent. 

OTOH, I wouldn't be the person on the shortlist 
of every programmer sociopath or technoTyrant for 
any amount of fame, glory, or money.  Not worth it.  So if they 
have to hunker down to do it, so be it.  I agree with the fellow 
who said, "standards organizations have to be accountable".  That 
is so.  The W3C was supposed to be a "technology enabler" and
unfortunately, 
some thought standards were a way to do that.  They aren't.  Standards 
are legal contracts.  Engineers are lousy lawyers usually and do  
not understand that manipulating process is nine tenths of a legal
practice. 
The other tenth is an incredibly thick skin and a loving spouse.

Last thought:  wasn't the USE of namespaces supposed to evolve in 
the application semantics?  IOW, what happened to running code and 
rough consensus?

len


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)