RE: Future XSLT expansion. ( Re: Microsoft XSL and Conformance )

["Didier PH Martin" <martind@xxxxxxxxxxxxx>]

Hi Paul,

> Jonathan Borden said:
> Again, the most important feature for me, not yet implemented is
document()
> support. Hint Hint...
>
> Didier replies:
> I cannot agree more on that. the Document() function is the angular stone
of
> web services usage based on URL request. Just imagine having the
possibility
> to make a SQL call with a URL and get back an XML document fragment.
> Furthermore, to be able to get within that fragment the exact
> element/elements through Xpath. As a concrete example:
>
> document('http://www.mysqlserver.com/sql=select * from mytable')/row/name

Paul said:
Just in case - why not

document('http://www.mysqlserver.com/sql=select name from mytable')

Didier replies:
Yes you are right, you can do that, So I probably picked the wrong example.
But I can assure you that in some cases you cannot access the element
directly from the URL. Just consider an other kind of URL request for a web
service:

document('http://www.moreover.com....and some other parameters-sorry I
cannot say morte without Moreover permission')/url

So, in that case the web service returns a full hierarchy of elements. The
XPath expression is used in that case to get the right elements.

Paul said:
> Yes indeed, the document function is where the magic potion is hidden

I don't think it is a good idea to turn XSLT into yet another monster
with things like that.

I think XSLT's extension elements could ( should ) do things like that.

( I actualy think that it could be better to remove some stuff from XSLT to
achive better balancing between core XSLT and extensions, but that's another
story.).

Isn't it  strange that fundamental node:set 'typecast'  is not in a core,
but some other things are in there ?

Didier replies:
So your opinion is that the document function part of the XSLT 1.0
recommendation is a monster? this is an opinion and I would respect it even
if I do not share it. Please Paul, think more about some concept that are
appearing on the web now:

a) the notion of web service: you do a URL request and get back an answer in
XML. Do you find that a monster? Is CORBA or DCOM better? if yes why?
b) the notion of content aggregation. If a posted document is an XML
document, a fragment of this document can be aggregated by an other document
using an XPath expression (i.e using the document function as an XPath
step).

Off course in the case of b) you can say that there are some serious
commercial problems. Certainly, if I can aggregate some content from Yahoo
without having the publicity popping in the browser, this may cause some
problem to the Yahoo's business model. Just from the last sentence, you may
have a clue why the Yahoos have no incentive to move to XML/XSLT content
publishing. I agree that it is hard to sustain the actual business model if
you provide pure information and not simply a rendition format (that
obviously includes some publicity - naturally, they have to make some
money... sorry, a lot of money not necessarily from sales but surely from
stocks :-)

So to conclude, it seems Paul that you do not want to drink the document()
function magic potion and that the notion of web service is more evil than
good new for you. Is this what you are saying or, once again, the monster of
email misinterpretation played some of its tricks. Note: Guys from Scotland
assured me that the monster of email misinterpretation has no parenthood
relationship with the loch ness monster - the former is the bad guy and the
latter the good guy.

Cheers
Didier PH Martin
----------------------------------------------
Email: martind@xxxxxxxxxxxxx
Conferences: Web Chicago(http://www.mfweb.com)
             XML Europe (http://www.gca.org)
Book: XML Professional (http://www.wrox.com)
column: Style Matters (http://www.xml.com)
Products: http://www.netfolder.com



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list