[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: XSLT wish list

Subject: RE: XSLT wish list
From: simon.2.thompson@xxxxxx
Date: Tue, 25 May 1999 11:58:50 +0100
Is it just me, or would the thing be for XSL to be able to compare values
across contexts as in 

<!--doggerel xslish follows-->
<xsl:template match= "/database/elementName[attribute
<!-- end doggerel xslish -->

although I might just be demonstrating the depth of my ignorance on the
subject, I can't find the syntax to do this in the current implementation
(ie 5). I think that this is a function of the way that the engine looks at
the current context, and cannot store an intermediate value. 

If it is possible to do this, or this could be done, then I think XSL
is/could be an absolute winner. As it is, I think that resorting to jscript
to store the intermediate values is just too messy for words (and certainly
for serious applications). 



Dr. Simon Thompson,
Intelligent Business Systems Research Group, 
Business Engineering Lab,
Advanced Communication Research, 
BT. Labs	

01473 605531 (phone)
01473 642459 (fax) 

www: http://www.labs.bt.com/people/thomps65/index.htm

On Saturday May 22, 1999 02:52, Duane Nickull
[SMTP:webmaster@xxxxxxxxxxxxxxxxx] wrote:
> Robert C. Lyons wrote:
> > 
> > Duane wrote:
> >        >   The error message should include the line number within the
> >        >   document of the invalid data.
> > 
> >        IE 5.0 does this right now.  In fact, it pukes on anything which
> >        not conform to the proper XML syntax (as it should).  A good
> >        should do this.
> > 
> > I was not referring to XML syntax errors (e.g., the source doc is not
> > or XSL syntax errors (e.g., the stylesheet contains an invalid
> > Instead, I was referring to application-level errors (e.g., a person's
birth date
> > is greater than the current date).
> > 
> I don't beleive that there should be any application-level validation or
> it will cause XML/XSL to lose some of it's extensibility.  The above
> example of a date validator may be nice but it will instrinsically
> increase the complexity of writing a good XML parser.  The tools are
> there for people to write their own methods, event handlers and error
> procedures.  I believe these should be used.  As far as IE 5.0 goes,  I
> have been using it since the first beta and it has been both a blessing
> and a curse as we found it to be very finicky.  It certainly forces me
> to keep up the quality of my work ;-)
> I do agree with you though that it may be nice to have a direct gateway
> to SSI's through an <xsl:cgi> tag or something similar.
> Another reason I am not in favor of this is the issue of
> forwards/backwards compatibility.  Imagine a person gets an XML/XSL
> parser written today for the current spec.  By default, such a browser
> should ignore tags it does not understand and not take any action.  This
> ensures that the parser (browser) will be able to operate tomorrow
> without generating 100's of application-level error messages whenever it
> encounters a tag/processing instruction/date etc that it does not like. 
> Again,  the current spec of XSLT/XML gives authors the tools to create
> their own level of additional validation above what is required by w3. 
> Each individual author can set their own parameters for what to do when
> errant data is encountered. 
> Duane Nickull
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

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

Current Thread


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.