This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: XSLT V 1.1



----- Original Message ----- 
From: David Carlisle <davidc@nag.co.uk>

> 
> > I guess you *can* put together some tricky mess 
> > of  &entities, 
> 
> entities are a widely used and standard part of XML, and I can't see how
> it helps to just ridicule people who use these features. XSL currently
> supports them and there is (I would hope)  no chance that a future XSL
> removes that support. Having multiple URI per document is likely to
> become more not less likely as support for xml base comes along.

1. I'm not saying that XSL should stop supporting entities
( and I never said that ).

I'm saying that by default document() should resolve URI's
relatively to current XML input  *not* to the current XSL 
stylesheet like it is now.

What is your argument against this statement ? 

2. *Another* point I'm making is that maybe having 
base URI being changed 'down the road' *is* possible,
but  I don't understand *how*  this is usable in the 
real life, that's  why I was asking for particular usecase.

Instead of providing the usecase you are now 
writing : "stop blaming entities". 

This is not about 'blaming entities'.  

Well, I do blame them, but this is *not* the point 
I'm making , that 'entities' is bad. I know they are bad. 
Because they are bad I'm not using them ( like XSLT 
itslef is not using &include, but stays with xsl:include ;-) 
Because I'm not using &entities - I'm not experienced 
in that &entity hacking - I simply can not see how 
to produce a reasonable usecase which will shift 
base URI's on-the-fly on purpose !!!! I can hink only 
about something artificial !

I'm suspicious about 'multiple URI per document' being 
reasonable architecture.  You are saying: "entities 
are common practice and simple document() will 
not work with some common usecases". I think it 
is consistent to ask: could you please  *show* that 
entities-sensitive usecase? I'm sorry if I'm 
asking for that usecase using bad wording. 
I apologize for all the bad things I said about 
XML &entities;. 

The question remains the same : how *in particular*  
usage of &entities makes problems to 'simple' 
document() ?

But again - this is *also* not important now.

My last letter says:

This thread takes long. *No matter* do you really 
have any usecase - let's inherint *current*  
"only current URI matters", but stop resiolving 
document() from URI of the stylesheet - there 
is no too much point in current 'default' behavior.
 
1. Put away hard-coded for-each
2. Resolve relatively to XML input, but not to XSL stylesheet.
3. Use "" ( or argv0 ) to resolve relatively to XSL stylesheet.

This will give *not* the document() we have now, 
but all the useful functionality of document() will 
be supported.

Maybe I'm wrong with (1), but I think I can not be wrong 
with 2 and 3 ( because I'm using current XSLT solution, 
just making it more consistent. )

Rgds.Paul.



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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]