Re: [xsl] Are there things missing in XSLT which force people to use, sa

On 10/29/2010 06:47 PM, Dimitre Novatchev wrote:
> On Fri, Oct 29, 2010 at 3:16 PM, Ben Mendis <ben(_at_)antennahouse(_dot_)com> 
> 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(_at_)antennahouse(_dot_)com
Web: www.antennahouse.com


--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--