Conformance errors and user agents

[domenic]

Is there any interest from user agents in actually exposing conformance errors? Or should that be left to validators?

[rubys]

Galimatias does. Mike Smith tells me that the W3C Validator uses Galimatias internally.

I don't know the state of browser interest in this.

Given this, what change would you suggest to the spec?

[domenic]

The sentences that struck me as a bit out-of-touch with reality was

By contrast, user agents are encouraged, but not required, to expose conformance errors somehow. If parsing a given input results in the detection of multiple conformance errors, user agents may chose to only report a subset of the errors detected.

at least when I was interpreting "user agents" as "browsers."

HTML gives conformance errors a much more detailed treatment:

• https://html.spec.whatwg.org/multipage/introduction.html#how-to-catch-mistakes-when-writing-html:-validators-and-conformance-checkers
• https://html.spec.whatwg.org/multipage/infrastructure.html#conformance-classes

No need to go into that much detail, but perhaps explicitly spell out what conformance classes this document is trying to encompass, and how each part of it applies. Presumably conformance checkers would be interested in exposing conformance errors, but I doubt user agents would be (and even if they started doing so you could argue that they have a built-in conformance checker taking over that part of the work).

[sideshowbarker]

perhaps explicitly spell out what conformance classes this document is trying to encompass

Yeah, I think the spec should explicitly define multiple conformance classes similar to the way in which the HTML spec does https://html.spec.whatwg.org/multipage/infrastructure.html#conformance-classes though of course it doesn't need as many classes as HTML does.

And I think the URL spec doesn't (shouldn't) necessarily use the term "user agent", which in practice strongly implies "browser" but could (should) define more specific classes.

But I guess a good set that it might define (1) a URL parser, (2) an error-reporting URL parser, (3) a URL serializer, (4) a "conforming document" (that contains URLs), (5) a URL conformance checker

But as far as conformance checkers as a class, I think that may not be necessary for the URL spec to state any; it'd only be needed for cases where we'd want to define specific actions that such a tool should take when it encounters particular instances of non-conforming URLs. But I'm not sure the URL wants or needs to be that specific about conformance-checker actions. I think the relevant requirements about what the checker would actually evaluate would be covered by the requirements for the "conforming document" class.

[rubys]

I'll need to experiment a bit, but takeaways so far:

• this section should be renamed "Conformance Classes", and I should move the definition of conformance errors and parse exceptions into this section.
• I don't believe "user agent" implies browser, and I believe I can make it more clear by using the term "Web browsers and other interactive user agents", following the lead of the HTML standard.
• Mike's proposed initial set of conformance classes looks like a good place to start.
• I believe that the right place to define document conformance requirements is in specifications that define documents. The right way to handle this in the URL Standard is to include prose similar to URL APIs elsewhere which includes suggestions as to how such specifications should be written.