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

[Paul Tchistopolskii <paul@xxxxxxx>]

Hi Didier,

> 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?

Not any data source could be represented by URI. Period.

Think about the data from servlet session. Think about the current values 
of http-reqest. Learn from experience of some people who are trying to make 
this XSLT thing work in the real life.

> 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.

Your design descisions  are creating overhead on almost *any* 
component.

"Let's continue bloating it because it is already bloated" is a consistent
view of course, but I just can't take it seriosly.

> 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.

Yes, in my letter all oppinions is mine. And I also guess that in your 
letters all oppinions are yours.  Great, it appears we have found 
some common ground here.

> 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.

What is not an argument? The impact of node-set typecast on the entire 
processing model of XSLT is not an argument? I think you could easily 
ignore an elephant if it will not fit into your picture.
 
> 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.

The point is that the world is not full of XML documents and only 
XML documents. HTTP request does not come in the form of XML
and unfortunately, it will take some time when it will.

> 
> 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.

Yes, it is. And to illustrate that point I found some words, explaining why 
the analogy between 'send/recv'  and 'document()' is correct. So far I am now 
not finding any arguments in your letters instead of 'OK it is your oppinion'.

If you'l not say "good point" about my comparsion of Tcl/Tk and perl 
I would not even try to explain to you that we have exactly the same 
situation with XSLT core. 

Unfortunately, I decided you can understand some things about the 
software other than "it is written on the page number NNN of 
document MMM". I was wrong, sorry about that and I see nothing 
to discuss here. Because:

1. Efficiency is not a problem to you.
2. Ease of writing extensions  is not a problem to you.
3. Elegant, balanced API is not a problem to you.
4. What is currently written in some paper is not a 
big problem to me. ( 1 - 3 ) is a problem to me.

Rgds.Paul.




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