On May 30, 2009, at 18:25, Jukka K. Korpela wrote:
> M@trixX wrote:
>
>> Line 19, Column 41: Bad value http://petra.underald.net:270/ for
>> attribute href on element a: PORT_SHOULD_NOT_BE_WELL_KNOWN in PORT.
>> <a href="http://petra.underald.net:270/">Server</a><br>
>>
>> I didn't find WHY this should be error, so i think that something's
>> bad in validator... Or I'm wrong?
>
> It's not an error,
The HTML5 validator treats URI/IRI RFC 'security considerations'
violations as errors.
See http://tools.ietf.org/html/rfc3986#section-7.2
It's a bit unclear how 'security considerations' in specs included by
reference should map to the concept of error / not in error.
> and surely not a reportable markup error, which is what a validator
> should report.
Surely a validator for language X should report errors that are errors
according to specs normatively referenced by the spec of X? (Note that
what actually is normative about referencing IRI specs is a bit in
flux right now, and the validator isn't quite up to date when the
document isn't encoded as UTF-8.)
> The W3C "Markup Validator" is more and more becoming a kludgy
> heuristic*) checker, a fairly obscure linter, especially when used
> to "validate" "HTML 5" documents.
The idea is that the errors reported by the HTML5 validator are backed
up by the HTML5 spec or its normative references (though the spec
doesn't have a proper reference section yet).
> This time it's obviously trying to say that port numbers in http
> URLs should obey some rules (which is something completely external
> to markup issues, comparable to whining about language style in text
> strings or about color choices).
Normative references may be "external" but they are as relevant and
requirements made in the body of the main spec, aren't they?
> The half-cryptic message, which is labeled as an _error_ against all
> reason, seems to say that port numbers should not be "well known",
> apparently referring to documentation of "well known port numbers", http://www.iana.org/assignments/port-numbers
>
> This is absurd, since it would mean that port numbers like 80 (the
> default for http URLs) and 8080 should not be used, since they are
> definitively "well known". So I would deduce that the error message
> says just the opposite of what its creators meant to say: port
> numbers _should be_ "well known".
8080 is above 1023 and, thus, is not 'well-known'. 80 is redundant,
since it's the default port for the http scheme.
> This would be somewhat questionable as a warning and just grossly
> wrong as an error message.
Yeah, it's a bit questionable if violations of 'security
considerations' should count as errors. It seems reasonable to report
them to document authors, and the API for extending RELAX NG with
datatype libraries doesn't make warnings possible.
> There is no reason to say, in a general-purpose checker, that
> unassigned port numbers (like 270) should not be used.
Perhaps you should raise this as an issue on the URI mailing list.
> For all that a checker can know, the document might be for private
> use in a private network, or an experimental document.
The HTML5 validator is designed to help authors who write documents
for deployment on the Web. If it's useful on private networks, it's a
coincidental bonus.
> (And for all that a markup validator proper can know, "http://petra.underald.net:270/
> " is a string of characters that matches CDATA as attribute type and
> must not be reported as a markup error.)
No, a validator can know that the value of the 'href' attribute on the
'a' element is required to be a valid URL. (However, the HTML5
validator is out of date and requires it to be a valid IRI instead.)
If by 'markup validator proper', you mean a "validating SGML parser"
per ISO 8879, I suggest upgrading your use of the word to the ISO/IEC
FDIS 19757-2 definition of "validator". The error is question is
produced by a datatype library that plugs into a deliberate extension
point of RELAX NG.
As for calling the HTML5 validator an HTML5 validator, please see http://www.w3.org/TR/html5/infrastructure.html#conformance-checkers
--
Henri Sivonen
hsivonen@iki.fihttp://hsivonen.iki.fi/