Michael Kay wrote:
> > Specifically, the XSLT spec suggests that when using the HTML 
> > output method, that the XSLT processor do some escaping of 
> > *non-ASCII* characters in the href, src, codebase, or other 
> > URI-type attribute value. The XSLT processor is not required 
> > to do so -- in my opinion, it shouldn't bother, because it is 
> > the author's responsibility to ensure that the value is a URI 
> > reference, not an IRI.
> 
> The spec uses the word "should" throughout the section on serialization.
> My interpretation is that this is because serialization is optional, not
> because all the individual aspects of serialization are mere
> suggestions.

Given the complete absence of the word "must" in that section, I considered
your interpretation as well, but then I thought "Surely James Clark wouldn't
have left it ambiguous. Should means should, not must -- simple as that." It
would not have confused matters any if "must" were used, since it would
phrased as "the HTML output method must do x y and z", which does not 
contradict the optional-ness of support for the HTML output method or any
other hints provided by xsl:output.

> I've also seen specs that try to define rather more clearly what they
> mean by "should": specifically: "should do X" means "must do X unless
> there is a good documented reason not to do so in the particular
> circumstances". It certainly doesn't mean "could do X if you feel like
> it".

"Should" might also be used when the specification would like to make it be a
"must" but does not want to impose a burden on the implementations, such as
when you allow extension functions to inject into your result tree string
objects that contain illegal characters. :)

Mike

-- 
  Mike J. Brown   |  http://skew.org/~mike/resume/
  Denver, CO, USA |  http://skew.org/xml/

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