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: XSLT Performance (was BLANK)



I don't see XML and MQ as alternatives at all.

MQ is a transport protocol with transactional semantics (very similar to
LU6.2).

XML is a transfer syntax (when used in this environment at least).

In fact, when MQ was being developed I suggested using something like XML
(actually, generalized data stream as used in mapped LU6.2 conversations) as
a syntax for MQ messages. Like many of my suggestions, this was (perhaps
wisely) ignored - such a capability was not already present in the SSI
product.

MQ is very much less efficient than XML when you compare them as transfer
syntaxes - there isn't one in MQ!

For my customers (and IBM's emphasis on XML in MQSI2 seems to indicate for
IBM as well), the combination of MQ with XML is extremely popular.

Yours
John F Schlesinger
SysCore Solutions

-----Original Message-----
From: Uche Ogbuji [mailto:uche.ogbuji@fourthought.com]
Sent: Thursday, February 22, 2001 9:19 AM
To: lyndavv@earthlink.net
Cc: xml-dev@lists.xml.org
Subject: Re: XSLT Performance (was BLANK)


> My customers have continued using protocols like MQ instead of XML with
XSLT
> for EAI in integration between components and automated workflow because
of
> performance issues.  When talking with David Turner (Microsoft), he calls
> them "perceived performance issues."  Is performance of XSLT
implementations
> for largescale EAI/B2B integrations real or perceived?

Well, how old is MQ Series?  How old is XSLT?  How old is XQuery?

MQ is efficient because it has developed its efficiency.  XSLT
implementations will have to do a lot of maturing before they catch up,
but so will XQuery implementations.

No one is saying that people move to Saxon, MSXSL or 4XSL for large-scale
document query.  My point is that XSLT has a sufficient framework that
with some lightweight additions, very efficient implementations can and
will emerge.


--
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: xml-dev-request@lists.xml.org