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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] loosely and tightly coupled systems and type annota tion

[ Lists Home | Date Index | Thread Index ]

The problem is, they aren't interoperable.  They 
are just portable.  And without strong typing, 
a database isn't terribly efficient.  One might 
want to stop and ask about XML databases and does 
one really need them.  If one stops with "XML 
will be applied as a serialization", one can 
get away with that.

Sick though ye may be, that's markup.  You can't 
have it both ways.   The specs are not XML except 
for XML 1.0.  That's core.  The specs can be as 
huge and crappy as people want to make them.  XML 
Doesn't Care, so a defense or an attack based on 
them that says "that ain't XML" is both correct 
and irrelevant.   SGML didn't allow one to 
build their own markup structures in the sense 
that just like XML 1.0, ISO 8879 was the whole 
of the law for SGML itself.  Yes, it had more 
options, true, but also irrelevant.  That was 
fixed when XML 1.0 was released.  This isn't 
ISO 8879 being discussed here and yet another 
"we'll blame SGML" argument is just noise.  This 
is the XML subset of SGML being discussed.

Now, where are your problems starting?  Not in 
XML, but in these "crappy" specs as you say. 

1. If you don't need XQuery, XSD, etc., don't 
use them.

2. If those who need them build them, you have 
no complaint.  That's their choice.

3. If those you need to work with require them 
you can

a) Explain what the problems are to those people in 
terms of those requirements

b) Not work with those who need them

c) Offer alternatives to meet those requirements.

One can't stop the W3C or any other organization 
or individual from exercising their right to build 
applications and systems using XML.  One can rightfully 
resist their claims that these applications and systems 
are essential parts of XML.  They aren't any more than 
a MS Word is a rightful part of C++.

It comes down to choices, quality of choices, and 
who chooses.   Right now, the WWW architecture is 
decided by the TAG and the voting members of the 
W3C.  The Internet is a bigger domain.  The W3C 
could resist SML but could not stop it.  The 
SML group could create SML but also had the 
responsibility to sell it.   They could not 
claim it was XML.  Again, one can't have it 
both ways.  That's simple enough.

My worry is when some bozo in charge decides that:

1.  Only W3C specifications will be acceptable 
    without reference to merit or application.

2.  Members here and elsewhere applaud a decision 
    like that.  That's technical groupyism.

3.  We have to support it because it shows up
    in an RFP and therefore, closes the circle of 
    "crappy" specs normatively referencing "crappy" 
    specs.

At that point, we all end up with redder noses 
and overinflated shoes.

I don't mind being wrong; I can learn.  I mind 
being right and irrelevant.  

len

-----Original Message-----
From: Simon St.Laurent [mailto:simonstl@simonstl.com]

> As long as that core remains untouched, all of the debates 
> on loose and tight coupling, schemas, strong typing vs 
> lexical and structural named types, are simply and 
> only choices of the application engineer.  

I have to admit that I'm incredibly sick of the "don't worry about how
huge and crappy the specs are - the application engineer just gets to
pick and choose the parts they want to use."

I thought we'd gotten past this hurdle when XML discarded all the
optional bits of SGML, rejecting the build-your-own-markup-structures
options in favor of creating systems that could be widely shared and
interoperable without profound and tedious negotiation.

XML 1.0 by itself seems to have been designed to avoid the need for such
negotiation, reducing the level of coupling needed to build useful
applications substantially at the outset.  As we move "forward", that
lesson appears to be getting utterly lost under a huge pile of features,
and now we have to negotiate all that crap yet again just to share
files.

Coming up with vocabularies is difficult enough without having to choose
from the feature set of "Greater XML".  Expecting that these extra
features won't make that process even more difficult over time seems
blissfully naive. 

If every application engineer was an island, I'd give this theory a tiny
bit of credibility.  As very few XML application engineers have that
luxury, I think it's time to stop pretending that Greater XML can be
ordered a la carte.




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS