Re: Hex NCRs in generated XML: nice, but hardly essential.

At 22:12 06/03/28, Bjoern Hoehrmann wrote:
 >
 >* Martin Duerst wrote:
 >>[...]
 >
 >The Recommendation is very clear, the requirement

 >  Escapes SHOULD only be used when the characters to be expressed are
 >  not directly representable in the format or the character encoding of
 >  the document, or when the visual representation of the character is
 >  unclear.
 >
 >is not optional and must be complied with unless there are specific
 >reasons not to,

Agreed. It is not optional, because that would be a MAY.

 >and in the rare and exceptional cases

Where did the 'rare and exceptional cases' come from?

 From http://www.ietf.org/rfc/rfc2119.txt:
3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
    may exist valid reasons in particular circumstances to ignore a
    particular item, but the full implications must be understood and
    carefully weighed before choosing a different course.

This says "particular circumstances", but does not go as far
as 'rare and exceptional cases'. A good general example would be
a SHOULD to take into account memory limitations on mobile and
embedded devices. Such devices are in now way rare or exceptional,
to the contrary, there are way more of them that PCs.

 >where there are
 >such specific reasons we have the requirement

You are correct about the fact that these two conformance criteria cascade.


 >  Content SHOULD use the hexadecimal form of character escapes rather
 >  than the decimal form when there are both.
 >
 >that is not optional either and must be complied with unless there are
 >specific reasons not to. These are conformance requirements,

The Character Model uses the term conformance criteria, not conformance
requirements!

 >not some
 >tips for cooler coding. I am planning to flag all violations of SHOULD
 >level requirements as Warnings in the Markup Validator, no matter
 >whether it's use of private use code points, choice of encodings, or
 >use of escape sequences. If that is not what you want, the document is
 >in error.

Claiming that a spec is in error based on some roundabout decisions
on a validator implementation is of course arguing in the wrong
direction.

A SHOULD always requires human thinking for the exceptions.
That means that it also requires some thingking when creating
a validator. If you plan to indiscriminately bomb the users of
the markup validator with an error message for each decimal NCR,
on top of the message that they use NCRs in the first place,
the resulting validator may be extremely correct (for some
measure of correct), but not very useful or helpful at all.

If you plan to limit the number of warnings of a specific type
(in the way e.g. all good compilers do), allow the user to easily
configure the warnings s/he wants to see, and so on, and choose some
reasonable initial settings for which warnings are and are not
shown, then at least I personally don't have anything against the
markup validator flagging these things with a warning.

Regards,    Martin.

Received on Thursday, 30 March 2006 09:55:22 UTC