[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] Are there things missing in XSLT which force people to use, say, Java to process XML?


Subject: Re: [xsl] Are there things missing in XSLT which force people to use, say, Java to process XML?
From: Ben Mendis <ben@xxxxxxxxxxxxxxxx>
Date: Sat, 30 Oct 2010 03:33:37 -0400

On 10/29/2010 06:47 PM, Dimitre Novatchev wrote:
> On Fri, Oct 29, 2010 at 3:16 PM, Ben Mendis <ben@xxxxxxxxxxxxxxxx> wrote:
>>
>> On 10/29/2010 12:13 PM, Michael Kay wrote:
>>>> I was just thinking that the current XSLT standard lacks interactivity, and was about to suggest an
>>>> element xsl:prompt for further revisions of the standard.
>>> Streaming in XSLT creates the intriguing possibility of using the interactive input and output as the
>>> primary input and output of the transformation, with XSLT used to transform one into the other.
>>>
>> A perfect use case for this would be XMPP (Jabber). XMPP works by opening two streaming XML documents, one
>> for reading and one for writing. Stanza of XML are read from or written to those streams to communicate
>> between the Client and Server. When working with XMPP there have been times when I've felt like "this would
>> be really simple in XSLT", but since it's a stream and not a document I end up using other languages. An
>> XSLT-like language for streaming XML would be nice, but XMPP is pretty much the only place I've ever seen
>> streaming XML.
> Just one small clarification:
>
> I think that the phrase: "streaming XML" or "streaming [whatever
> language-format here]" is incorrect, because you only know that you
> are streaming XML only at the end of the streaming.
>
> It may perfectly well be the case that at some later stage of the
> streaming you will discover that the text being streamed isn't
> well-formed XML (not even to speak about valid XML)
>
> Therefore, a more precise expression would be: "streaming what so far
> appears to be XML".
>
> This has some serious implications if the processing has side effects
> (for example modifying some data based on the streaming processing).
> In case we are broken halfway through, it may be necessary and should
> be possible to reverse the actions taken so far. Thus, it is a good
> idea to perform streaming in transactional mode.
>
> I apologize if I am stating something obvious.
>
In the case of XMPP, the specification states that it must be XML. Therefore, it is a reasonable assumption
that what is received will be XML. I believe that the concern of corruption on-the-wire is handled
effectively by the consistency assurance mechanisms in TCP and therefore not a concern.

Of course as developers we need to code defensively and anticipate malformed data, however I think that is
outside the scope of my original observations regarding the usefulness of XSLT and XQuery in the context of
streaming XML.

-- 

Ben Mendis
Support Specialist
Antenna House
10410 Kensington Pkwy
Suite 207
Kensington, Maryland 20895
USA
Phone: +1 240-752-6687
Email: ben@xxxxxxxxxxxxxxxx
Web: www.antennahouse.com


Current Thread
Keywords