On Wednesday, April 23, 2003, at 05:57 PM, J.Pietschmann wrote:
S Woodside wrote:
and others where failing is better.
Can you explain a situation where that would be better?
Let's say the data used in building the URL passed to document() is
hand edited. You usually want to catch misspellings and similar
problems, conveniently signalled by the processor raising an error.
...and just as conveniently signalled with a warning. This is just an
argument to make it a switch, since both uses are equally valid. Or
like in gcc to have a -Werror switch.
Well, if I could wave my magic wand and change the spec, the least
intrusive change would probably be, to add a document-exists() function
that doesn't give a warning OR an error.
Since the spec is ambiguous, and people have complained about it on a
number of occasions, without a satisfactory answer, therefore there
is a problem with the spec.
If you dig deeper you'll uncover a lot more problems with document(),
both for users and implementors. For example, accessing the URL might
have side effects in the server, and some people want to access the URL
for this reason each time document() is called even if the processor
has accessed and cached the content already. This may seem odd, but
there may be real world use cases. The spec is completetely silent
about such details.
Yes, certainly this is possible. However, personally I don't care about
that :-P
If you include all the more unconventional stuff in the spec, it
becomes bloated, harder to understand and much harder to check for
inconsistencies and internal contradictions. Also, resources for
producing a spec are quite limited in general.
I'm not suggesting anything of the sort. There is a problem, it has
been identified numerous times, if you google for "xslt" "document" and
{not found, exists, non-existant, missing} you'll see that.
It is ridiculous to say that, just because there are other problems
that can also be imagined, makes this particular problem any less
interesting.
simon
--
www.simonwoodside.com -- 99% Devil, 1% Angel
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list