[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Why XML for Messaging?

• To: 'Amelia A Lewis' <amyzing@t...>, xml-dev@l...
• Subject: RE: Why XML for Messaging?
• From: "Bullard, Claude L (Len)" <len.bullard@i...>
• Date: Wed, 1 Jun 2005 15:28:41 -0500

From: Amelia A Lewis [mailto:amyzing@t...]

On 2005-06-01 15:21:36 -0400 "Bullard, Claude L (Len)" 
 
> No.  There are better syntaxes than XML for messaging.

>Are there?
>What are they?

Neil Kipp posted one some years ago.  I can't find it now. 

Then there is the RELAXNG Compact Syntax that looks a lot like the VRML 
syntax.  In fact, that is one of the 'areas of innovation' 
that is fun to discuss.  Have a contest to see who can 
create the most terse syntax, or in other words, what 
happens if we take the original XML development requirements 
and invert them? (eg, terseness is of maximum importance).

>For particular messaging infrastructures, particular, often 
>proprietary or opaque data models have useful characteristics 
>(compactness, domain-specific expressivity, compatibility with 
>processing models).  Unfortunately, these data models often cannot be 
>shared, for one reason or another (proprietary, tied to an 
>architecture, or simply fragile).

Sort of how the Infoset is *shared* among the implementations 
of XML applications?  Ok, I do understand application-specific 
data models.

>... Customers, on the 
>other hand, sometimes nod solemnly, promise to think about it, then 
>look for a third-party that can provide performance enhancements over 
>the [transparent] XML message formats.

Yep, or vendors have products and insist on them over those spec'd 
in the RFP.  We see that in the graphics domain a lot or wherever 
there is a fast tracked project with hars performance.  What is 
happening now as a result of the XML hype, the User's Group attendees 
who listen but either don't know what will happen when the kool-aid 
kicks in or don't care, is that we see XML forced lower into systems 
where the fit is very bad, but the W3C looks back at the groups trying 
to solve that AND have XML systems interoperability and asks for proofs 
prior to performance.  (IOW, if this discussion had been had for XML, we 
wouldn't be using it at all.  Oh for those naive days again...)

>*shrug*  In this particular space, it appears that the customers are 
>driving toward XML, or at least toward some structured, expressive 
>message data format with high transparency and public guardianship.  
>Perhaps they're overestimating the utility of XML, or underestimating 
>its cost, but it does appear to be a customer-driven push, not 
>trade-secret vendor koolaid with miraculous healing powers.

I agree.

Why XML Messaging?  For the sake of standards.  I'm cool with 
that until it means the system won't deliver on performance. 

Quick:  Did a 737 REALLY hit the Pentagon?  Of course it did. 
Then where is the wreckage?  Umm.  I don't know, but we have a 
photo of it.  Umm... no you don't,  There are exactly four snaps 
and when something is traveling 530 mph 2 feet off the ground, 
you only get a piece of one.

Ok then, faster photos.  Fine, but can I upload those in real time? 
Nope.  Too big.  Well, what if I take out some of this markup? Ok, 
but that ain't standard.  

Welcome to real time sensor systems. 

1) It pays to question assumptions about standards.
2) It pays to make sure the RFP authors understand the assumptions.
3) That should be a dominant topic at XML User Groups particularly 
   in areas where RFPs are issued with big dollars.

len

• Follow-Ups:
  • Re: Why XML for Messaging?
    • From: Jonathan Robie <jonathan.robie@d...>

• Prev by Date: Re: Why XML for Messaging?
• Next by Date: RE: Why XML for Messaging?
• Previous by thread: RE: Why XML for Messaging?
• Next by thread: Re: Why XML for Messaging?
• Index(es):
  • Date
  • Thread