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

Subject: RE: Future XSLT expansion. ( Re: Microsoft XSL and Conformance )
From: "Didier PH Martin" <martind@xxxxxxxxxxxxx>
Date: Sat, 18 Mar 2000 00:08:50 -0500
Hi Paul,

Paul said:
Now what is the way it should be wih document(URI);
---------------------------------------------------------------------------

document(URI) ( like any other 'grabber-of-data' )  should return text
but not node-set,  but node-set  typecast  should be in the XSLT core.

1. This allows user  to import some XML document *not* converting
it into node-set ( not the way current 'polluted' document() works)
BTW, could you achive this functionality with XSLT ? Just insert some
external document into the output ? Why should everything  be
always  'converted'  to node-sets, 'processed'  an then turned
back into text? I guess the only answer is 'because we see it this way'.
Good for you,  but limiting.

2. If user wants to achive the current document() -> nodeset conversion,
she should use the node-set typecast explicitly.

3. Such design allows easy writing engine-independed extensions
( passing text to/from extension,  but not node-set's)

Isn't it obvious that the way taken by XSLT document() is perlish ?
Still not ?

Didier replies:
 not necessarily. I you mean that having a node tree is perlish, so yes you
are right the construct is perlish since the concept of having a node tree
is perlish. But to have the document returning a node set make sense
especially if you use the following construct:

<xsl:apply-templates select="document('....')/elementx/elementy"/>

In fact the document function is probably more useful in this context than
to simply get pure text. At least a node set can be processed.

Paul said:
My question is: do you see any way to utilize document()/part
hack when you have multiple document trees / sources, or document()/part
hack could be utilized only when processing multiple XML files ( something
identified by URL ) ? The *real* semantics of document()/part is:

1. Give me some data from the outher space.
2. Filter that data with some criteria.

The 'outher space' is considered to be XML file and only XML file + it
should
be *nodeset and only nodeset*.

This is not scalable and very limiting. Not all the data in this world
are XSLT vendor-specific node-sets.

Why should SQL engine bother itself with conversions of some table
into 'one-root-nodeset-alike' structure ( XSLT vendor specific nodeset
structure).

Didier replies:
Error, the sql vendors will provide XML documents not node sets. So why are
you talking about node set returned by sql servers here?

Paul said:
It is XSLT paranoya to see everything in this world as
XSLT-vendor-specific-node-sets.

Didier replies:
Take note here that you said that, nobody else said that and more
particularly not me. SQL vendors provide XML documents in text format not
node sets. However, this XML document is transformed into node set for
processing.

Paul said:
XSLT is better to solve it's paranoya by itself. ( placing  node-set
typecast into the core , but if making that step - what is the purpose of
having current document() semantics? No purpose, instead of
perlish 'send/recv and read/write'  e t.c. )

I wish it is now clear.

Didier replies:
Its your opinion.

Paul said:
You are welcome. Because I have an impression that you don't
understand what that realy means I have explained it once again
in more detail. I'm sorry if that was disturbing.

Didier replies:
What was disturbing Paul is that you said that I proposed this and that this
is not part of the specs. Sorry, you said that. And no, up to date I do not
see any convincing arguments, just opinions and opinions are undisputable.

Paul said:
Yes. That's what I'm saying.

'documents other than the main source document'. This assumes the world is
full of XML documents and only XML documents (XML files) are to be
processed.

That's just funny. That's what I was trying to explain.

Didier replies:
So... What is the point here.

Paul said:
Of course it is valid. It is just ugly. I'm not saying 'send/recv' are
illegal in perl.
My point is that perl is a monster. And also my point is that with
document()
hack XSLT choosed perl-ish way.

Didier replies:
OK its your opinion.

Paul said:
Core XPath engine type is vendor-specific 'node-set' and there is no
type-cast to that type in the core. That's just funny, you don't see a
problem here.
That  *is* a problem. A  *real*design*problem*, forcing logical hacks ( like
document()
hack )

Didier replies:
Do you mean here that a vendor may choose to return text from a document()
function and an other a node set? I guess that we are still talking within
the boundaries of XSLT 1.0 recommendations.

Conclusion: Based on my experiments I discovered that the document()
function is very useful. I just say that: useful. If you think this is not,
the choice is obvious, do not use it.

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


Current Thread