xml-dev - RE: interoperability (was Re: Obfuscating XML with namespaces)

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

Trust but verify.  They are not required; just 
useful.  If they use them well, they prosper. 
If not, they patch.  Patching costs money.  
Darwin rules.

If the interoperability enablers become 
like snatching bits of hits to get a rap 
or hip hop arrangement, then the yawn factor 
will out.  Style counts.  One can macro 
anything and call that design, and at some 
level, it is.  Madeleine Sparks used to 
beat me up about setting out to design 
something without clear and precise requirements. 
Some believe in loose requirements and winnowing. 
Some believe in tight requirements and testing. 

Ya gets what ya puts in.

Cost/benefit for the XML family of specifications: 
that would be an interesting study.  I can do 
without a lot of them given other infrastructure. 
XLinks are neat, but not the only way to get 
that job done.  XPath is crucial for working 
with XML trees, but I can do the same thing 
with a relational database.  It really depends 
on just how far one wants to push XML as an 
application enabler.  In most cases, I see 
it as a bridge and a means to get a long lifecycle
storage format.  InfoSet is critical to the 
abstraction so XML is not just a syntax.  I need 
DTDs and schemas for obvious reasons.  Namespaces  
are a tactical convenience.

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: Simon St.Laurent [mailto:simonstl@simonstl.com]

I'd advise developers to take a look at the entire context of their
contracting negotiations, and not rely on namespaces and schemas to solve
their problems for them.  They can be useful tools, but I don't think
they're either required or complete.

At the same time, I'd like to see the organizations handing down the
infrastructure standards take a good look at how to make these things more
usable with their own standards, so that these interoperability enablers
don't turn out to be roadblocks.  Right now, I'm not very happy with the
cost/benefit ratio of a lot of the specs that are supposed to make XML
better or more interoperable.