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.
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.
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. This means there will
always be room for some people to bitch and moan about holes and
ambiguities.
J.Pietschmann
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list