You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by Brian Minchau <mi...@ca.ibm.com> on 2006/12/12 01:35:56 UTC
A question on how users are using
Way back in history it seems that <xsl:message> produced just the message,
but then some users asked for location information in the stylesheet of
where the message was coming from.
Recently XALANJ-2340 asks us to remove that location information, perhaps
with some option. So the questions for users are:
How are you using <xsl:message>?
Is it being run on a server, or web-server, and the output of
xsl:message going to stderr and caught in a log and processed by other
tools, or what?
What would happen for you if we removed the location information?
- Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: A question on how users are using
Posted by Mike Brown <mi...@skew.org>.
Brian Minchau wrote:
> I know that Xalan has some extension attributes for xsl:output ... but now
> that I think about it ... where in XSLT 1.0 recommendation does it say that
> this is OK?
XSLT section 2.1:
"An element from the XSLT namespace may have any attribute not from the XSLT
namespace, provided that the expanded-name of the attribute has a non-null
namespace URI. The presence of such attributes must not change the behavior of
XSLT elements and functions defined in this document. Thus, an XSLT processor
is always free to ignore such attributes, and must ignore such attributes
without giving an error if it does not recognize the namespace URI. Such
attributes can provide, for example, unique identifiers, optimization hints,
or documentation."
So, you can add extension attributes as long as they don't change the
specified behavior of the element. So for example it is wrong (even though
Saxon does it) to have an extension attribute on a non-empty XSLT 1.0
xsl:variable element that causes it to create a node-set instead of a result
tree fragment. But having xalan:location-info="no" on xsl:message wouldn't be
harmful or against spec.
I agree though that it'd likely be something people would want to control
globally, as well as per-message.
As for what I use xsl:message for:
- debugging: often doing copy-of on a variable to see what it is
- tracing: "got here"/"now doing X" kinds of messages that I want to be logged
- validation: abort processing if crucial info missing; warn re: other issues
Also in the debugging and validation veins, I often write stylesheets that
walk a tree and process whatever is found. I'll set up templates to handle
certain nodes, and a generic template that handles anything I forgot to create
a more explicit template for. In that generic template will be an xsl:message
saying something to the effect of "FIXME". A top-level param might be used to
control whether the xsl:message is actually invoked.
Mike
Re: A question on how users are using
Posted by Brian Minchau <mi...@ca.ibm.com>.
Hi Dave,
what element would this attribute be on? The xsl:message element?
I know that Xalan has some extension attributes for xsl:output ... but now
that I think about it ... where in XSLT 1.0 recommendation does it say that
this is OK?
I don't know if users want to change individual xsl:message elements in
their stylesheet, or if they want to specify some global change say via the
Transformer.setParameter(String,Object), say
Transformer.setParameter("{http://xml.apache.org/xalan}message-location",
"no"); ?
- Brian
david_marston@us.
ibm.com
To
12/12/2006 09:46 xalan-j-users@xml.apache.org
AM cc
Subject
Re: A question on how users are
using <xsl:message>
Brain Minchau asks:
>How are you using <xsl:message>?
Okay, I'll start.
I am using it strictly in interactive usage, either for progress
tracking messages or for debugging. Most of the time, the location
information is either desirable or not a problem. It would be nice to
have an attribute (e.g., xalan:location-info="no") to control it.
I would also be interested to hear if anyone has warmed up to the
notion that xsl:message can emit something other than a string. The
spec (part 13) grants leeway for xsl:message to issue elements or
whatever, though I think strings in the body should never be
ignored.
.................David Marston
Re: A question on how users are using
Posted by ke...@us.ibm.com.
My personal inclination is to output only the message that was asked for.
The API may want to tell us more than that -- perhaps to help folks who are
writing XSLT debuggers? -- and I've no objection to folks plugging in an
error reporter which includes that info. I don't even have a very strong
opinion on whether that or the bare message should be the default as
shipped, as long as the bare version is available as default by setting the
appropriate properties file and/or command-line option.
However: Given the problem of not always having a meaningful stylesheet
URI, and not always having line breaks and the question of byte offsets
versus character offsets, there's a real question about how to report the
message's location. My own preference, when dealing with location in an XML
file, is always to provide an XPath to the location since that avoids the
latter issues at least...
______________________________________
"... Three things see no end: A loop with exit code done wrong,
A semaphore untested, And the change that comes along. ..."
-- "Threes" Rev 1.1 - Duane Elms / Leslie Fish
(http://www.ovff.org/pegasus/songs/threes-rev-11.html)
Re: A question on how users are using
Posted by da...@us.ibm.com.
Brain Minchau asks:
>How are you using <xsl:message>?
Okay, I'll start.
I am using it strictly in interactive usage, either for progress
tracking messages or for debugging. Most of the time, the location
information is either desirable or not a problem. It would be nice to
have an attribute (e.g., xalan:location-info="no") to control it.
I would also be interested to hear if anyone has warmed up to the
notion that xsl:message can emit something other than a string. The
spec (part 13) grants leeway for xsl:message to issue elements or
whatever, though I think strings in the body should never be
ignored.
.................David Marston
RE: A question on how users are using
Posted by Timothy Jones <Ti...@syniverse.com>.
Thanks for collecting input from us. I have been using xalan in my
applications for nearly 6 years, in various web containers
(jboss/tomcat4 for dev, SunOne AS 8.1 in production).
My app assembles Oracle database records into XML trees, then transforms
the tree with an XSL stylesheet that produces (X)HTML output. If RTF
format is desired, a second transformer is used to transform the HTML
into RTF. These stylesheets use xsl:message with the terminate='yes'
attribute to abort the transformation if critical pieces of the input
tree or incoming parameters between XSL templates are missing or
invalid. The output is caught and logged in the webserver, but only a
generic error is shown to the user.
I have just read the JIRA record at
https://issues.apache.org/jira/browse/XALANJ-2340, and I would not have
a problem with the addition of a command-line switch to suppress it, as
long as the location information remains intact in the other contexts.
Timothy Jones
-----Original Message-----
From: Brian Minchau [mailto:minchau@ca.ibm.com]
Sent: Monday, December 11, 2006 7:36 PM
To: xalan-j-users@xml.apache.org; xalan-dev@xml.apache.org
Subject: A question on how users are using <xsl:message>
Way back in history it seems that <xsl:message> produced just the
message, but then some users asked for location information in the
stylesheet of where the message was coming from.
Recently XALANJ-2340 asks us to remove that location information,
perhaps with some option. So the questions for users are:
How are you using <xsl:message>?
Is it being run on a server, or web-server, and the output of
xsl:message going to stderr and caught in a log and processed by other
tools, or what?
What would happen for you if we removed the location information?
- Brian