«

> >It is too bad that xslt makes it so
> >difficult to do these simple checks.
>
> XSLT syntax is _meant_ to be difficult. It's not for humans to write,
> it's for machines to write. The original "grand plan" involved much
> smarter editors and CASE tools which hid the admitted lumpiness of the
> line-by-line syntax away from the users.

I can accept this, but then I need that grander technology.
So far I am unaware of a good solution to the problem I mentioned. In
practice xslt is being written by hand right now. It is a very
successful technology (arguably the only majorly succesful xml
technology around today, but that is opening a can of worms), and the
way it is being used probably won't change for some time. People need
solutions now, and until xslt can address this problem it will be left
out of considerations for many projects.

> >I would definitely vote to
> >somehow add a mode or something that would complain if an xpath
> >expression doesn't exist.
>
> This is really bad and wrong. The values of XPath expressions don't
> "not exist", they evaluate to empty sets. If you think about the
> programming environment in the right way, as a calculus, then this is
> the obvious way to do things. And you _have_ to think about XSLT the
> right way, for if you don't , then it will bite you.

As mentioned in a response above, I thought I was being clear
when I used the phrase "not exists" I really meant node set size=1,
but I guess by the double response about this that it wasn't so clear.
The point is that it is very common to want to check for the unique
existance of a value-of item. If you would like to address your mail,
you would use the following transformation

<xsl:value-of select="name" />
<xsl:value-of select="address" />

and if the original xml is missing the name or address, or if they
appear more than once, you would like to know. Without redundancy or
much extra work (which will kill a group project) this is impossible
with xslt as it stands. This will preclude xslt from many projects
until either modifications are made, or until the appropriate big
picture technology is written around xslt.

Looking forward I believe that xslt (or similar technology) it
the right way to do many things, so it is unfortunate it it is missing
something so basic right now.

thanks
-I

You may prefer XSLT2 (draft, as implemented so far just in saxon this
allows you to specify the expected type of expressions and you'll get a
type casting error if teh returned expression doesn't have the right
type (eg it's empty)

David

In article < >,
inquirydog <> wrote:

% For starters, it is redundant. There should be a way to do
% the test without having to retype the xpath expression in twice (it

How about putting the results of the expression in a variable and
testing that? Sure, the programmer will have to do it, but I guess
the programmer has to get something right somewhere along the line.
Surely you don't want your entire process to be dependent on every
XPath expression returning data.

You can use xsl:message with terminate='yes' to have the script exit
immediately.

Now, you're probably right that there's a deficiency here, but unless
you come up with a concrete, workable syntax that resolves your specific
problem, it's difficult to discuss its merits.
--

Patrick TJ McPhee
East York Canada

"inquirydog" <> wrote in message
news: om...

--snip--

> The point is that it is very common to want to check for the unique
> existance of a value-of item. If you would like to address your mail,
> you would use the following transformation
>
> <xsl:value-of select="name" />
> <xsl:value-of select="address" />
>
> and if the original xml is missing the name or address, or if they
> appear more than once, you would like to know.

--snip--

Sorry for getting into this thread so late...

As far as I can tell, you want to check if an XPath expression evaluates to
an empty node set, and if so, report this as an error. To me, this is the
job of a schema (XML Schema, DTD, Relax, ...). If you do not have a schema,
all bets are off, and you need to check the conditions yourself, in the
stylesheet or in another way. Personally, if I would need to transform an
XML document without a schema, I would do some basic checks using Schematron
(or a custom stylesheet), before transforming.

What I am trying to say is that I think it is necessary to separate the
transformation from the "validation".


// Magnus

(inquirydog) wrote in message news:<. com>...
[wanting to ensure that a node-set is not empty before using it]
> So far I am unaware of a good solution to the problem I mentioned.

Honestly, I can't see what's not 'good' about sending the result of
the expression into a variable and then testing that variable; exactly
as if you wanted to check that, for example, a numeric expression
didn't evaluate to zero.

Can you write a schema for your input documents, and validate them
against that before running the stylesheet?
--
Robin Johnson
Lead Developer, enCircle Solutions Ltd.
first initial last name at encircle dot co dot uk

"Magnus Henriksson" <> wrote in message news:<cgc892$b1k$>. ..
>
> Sorry for getting into this thread so late...
>
> As far as I can tell, you want to check if an XPath expression evaluates to
> an empty node set, and if so, report this as an error. To me, this is the
> job of a schema (XML Schema, DTD, Relax, ...). If you do not have a schema,
> all bets are off, and you need to check the conditions yourself, in the
> stylesheet or in another way. Personally, if I would need to transform an
> XML document without a schema, I would do some basic checks using Schematron
> (or a custom stylesheet), before transforming.
>
> What I am trying to say is that I think it is necessary to separate the
> transformation from the "validation".

I fully agree with this in theory. The problem is that given
the way that schemas and xsl work today this solution is very flawed.
Most of the problems that I mentioned above are still not fixed. For
instance, the xpath expression must be expressed somehow redundantly
(in the transformation and in the schema). This is a big problem if
there is a typo in the xslt transformation- ie my schema makes sure
that I have an element called <dogname>, but the transformation tries
to use <dawgname>. Oops! Now my results are incorrect and no one is
there to tell me about it. Second, someone might change the
transformation and forget to change the schema. Again trouble. Third
it requires the developer to do much extra work for simple things.

Modularity in schemas vs transformations would probably be a
good thing in the final solution to this problem, but as it stands
today the present solution isn't very useful.

thanks
-I

(Patrick TJ McPhee) wrote in message news:<>...

>
> How about putting the results of the expression in a variable and
> testing that? Sure, the programmer will have to do it, but I guess
> the programmer has to get something right somewhere along the line.
> Surely you don't want your entire process to be dependent on every
> XPath expression returning data.

Definitely not! But there needs to be a simple way to test
for the existence of data for the cases that you need to, which I
think would be often.

> You can use xsl:message with terminate='yes' to have the script exit
> immediately.

I didn't know about that. That is quite useful to know
actually (solves part of the problem).

> Now, you're probably right that there's a deficiency here, but unless
> you come up with a concrete, workable syntax that resolves your specific
> problem, it's difficult to discuss its merits.

I don't know what was not concrete about the solutions I mentioned
earlier

> Could be many things. Perhaps a global processing directive that
> changes the default to expecting that a value-of be non-empty, or to
> exactly contain one item. Perhaps an extra attribute in a value-of to
> expect this (complainIfEmpty="true").

but at any rate I've thought about it some more and have another
perhaps better solution. What about inventing new elements like
value-of with type checking in them, like

<xsl:unique-value-of select="xpath expression"> (checks for
one and only one node in the node set).

and other common patterns

<xsl:value-of-list select=xpath expression" separator=",">
(prints out a list of nodes separated by the separator, checks that
the list has at least one element)

<xsl:apply-unique-template select="xpath expression"> (works
like xsl:apply-templates, but checks that the node set is of length
one).

<xsl:list-apply-template separator="," select="xpath
expression"> (works like xsl:apply-templates, but checks that the node
set has one or more elements, and puts the separator between the
outcomes of the apply templates).

thanks
-I

(Robin Johnson) wrote in message news:<. com>...
> (inquirydog) wrote in message news:<. com>...
> [wanting to ensure that a node-set is not empty before using it]
> > So far I am unaware of a good solution to the problem I mentioned.
>
> Honestly, I can't see what's not 'good' about sending the result of
> the expression into a variable and then testing that variable; exactly
> as if you wanted to check that, for example, a numeric expression
> didn't evaluate to zero.

Sure, I *could* just write the whole thing on a universal
Turing Machine and get the same results, but why would I want to. In
many cases to do the value-of properly the work needed to do that will
be so great that most people will not do it, and as a consequence most
xslt transformations will not be written to a reasonable enough
quality that they will be used in the business community.

I was going to write a simple example of a transformation
written with just value-of vs full out properly to show you the amount
the proper way would bulk it out, but decided I don't even want to do
that. XSLT right now makes certain checks very difficult.

> Can you write a schema for your input documents, and validate them
> against that before running the stylesheet?

See email above.

thanks
-I

On 27 Aug 2004 14:40:05 -0700, (inquirydog)
wrote:
[...]
>This is a big problem if
>there is a typo in the xslt transformation- ie my schema makes sure
>that I have an element called <dogname>, but the transformation tries
>to use <dawgname>. Oops! Now my results are incorrect and no one is
>there to tell me about it.

Yes, if you type the wrong code, you'll get the wrong results.

I can't think of a language that doesn't have that 'limitation'.
--
Robin Johnson
Lead Developer, enCircle Solutions Ltd.
first initial last name at encircle dot co dot uk

Robin Johnson <> wrote in message news:<>. ..
> On 27 Aug 2004 14:40:05 -0700, (inquirydog)
> wrote:
> [...]
> >This is a big problem if
> >there is a typo in the xslt transformation- ie my schema makes sure
> >that I have an element called <dogname>, but the transformation tries
> >to use <dawgname>. Oops! Now my results are incorrect and no one is
> >there to tell me about it.
>
> Yes, if you type the wrong code, you'll get the wrong results.
>
> I can't think of a language that doesn't have that 'limitation'.

Actually, I can't think of a language which doesn't catch typos-

-----

c:

printq("you dude\n");

compilation result:

In function `main':
: undefined reference to `printq'
collect2: ld returned 1 exit status

---

perl:

x = x + &;

run result:

line 4: syntax error near unexpected token `;'
line 4: ` x = x + &;'

---

java:

static public void main(String args[])
{

File file = new File("qq");

file.createNewFile();

}

compilation:

test.java:13: unreported exception java.io.IOException; must be
caught or
declared to be thrown
file.createNewFile();
^
1 error

(one of the reasons that I love Java is because it is great at compile
time error checking, finding perhaps 90% of my bugs right off the bat)

---

I am merely requesting that xslt have the same error checking
capabilities as just about every other language out there (it does in
some ways, but I am pointing out what I consider to be a large
ommision in the language). Using a schema to check that address.xml
has a <street> element in it like this

<xsd:element name="street" type="xsd:string" />

and using an xslt transformation with the following typo

<xsl:value-of select="name" />
<xsl:value-of select="stret" /> <-- typo, should be street
<xsl:value-of select="city" /> <xsl:value-of select="state" />
<xsl:value-of select="zipcode" />

would contain an error that should be but is not caught by the xslt
translation software. Granted, as some have pointed out here, you can
store all xpath expressions in a variable, do a test with instructions
to complain and stop processing, and then use the value-of with the
variable, but given that 1). Most people won't do this, and 2). It
could increase the size of many otherwise simple transformations by
probably double (ie- consider how big my simple example above would
become), I don't think this is a reasonable way to do things.


I believe that xslt is the way of the future of development, and am
eager to patch all the holes and growing pains that all new
technologies experience. I've given some of what I believe are
reasonable suggestions about how I think that should be done, if you
have a tangible reason why you think they are a bad idea, I would love
to listen. I am not sure how essentially saying -all languages have
problems- and throwing up your arms moves xslt forward.

thanks
-I