W3C home > Mailing lists > Public > www-validator@w3.org > January 2007

Re: A simpler Web service response format

From: olivier Thereaux <ot@w3.org>
Date: Wed, 31 Jan 2007 16:23:30 +0900
Message-Id: <30776F39-092E-4544-82BE-FA29011F9AD6@w3.org>
Cc: Karl Dubost <karl@w3.org>, www-validator Community <www-validator@w3.org>
To: Henri Sivonen <hsivonen@iki.fi>

Hello Henri.

Thanks for giving more of your thoughts on the topic.

Regarding grouping and counting messages, I wonder if the results  
format could not be  made friendlier at the same time to server/ 
validator and client.

For example, if

* all messages are required to be within a <messages> group, but not  
required to be grouped (but could be, if that makes sense for a  
certain tool - I think it would be best to keep them grouped for the  
CSS validator, or at least make it an option -

* count information could be put at the end of the results stream,  
and not require the service to gather all results before sending  
them. Ditto, in such a case, for any boolean passed/failed result.

(note that count is not required in unicorn response format at the  
moment. I still think it is useful, and would actually recommend to  
provide it always)

> One problem with counting errors is that in many cases the number  
> doesn't have a well-defined meaning. For example, the first error  
> may be serious enough to cause spurious later errors to be reported  
> because the first error changed the state of the validator in a bad  
> way.

Yes, that's a reasonable point. But a count, especially a count of  
error, still gives  a decent metric of how much work would be  
necessary to fix the problems. Most checking tools I know of and use  
(be it validators or compilers/lint) have this feature and it is not  
something I'd like to live with.

>>> * The SOAP format has SOAP namespace cruft. The Unicorn format  
>>> has XSD cruft.
>> I think these are reasonably cheap, especially if the benefit is  
>> being processable by more engines (soap-enabled ones, schema-based  
>> parsers, etc.).
> To me, it seems that it is a design bug for a schema-based parser  
> to require schema artifacts in the document instance. What kind of  
> interop has been achieved with the W3C Validator SOAP interface and  
> off-the-shelf SOAP stacks?

WebService::Validator::CSS::W3C [1] and the equivalent perl module  
for feed validator use SOAP::Lite library quite succesfully. On the  
other hand, other tools such as WebService::Validator::HTML::W3C [2]  
seems to be happy using just XML::XPath.

[1] http://search.cpan.org/dist/WebService-Validator-CSS-W3C/
[2] http://search.cpan.org/dist/WebService-Validator-HTML-W3C/

> I meant that as markup aesthetic attributes vs. child element  
> content and machine readable vs. human readable consideration, the  
> line and column numbers could well go in attributes.

I see. How about other context information? e.g the unicorn response  
spec has a context element, which could be made to hold any kind of  
CDATA, such as a snippet of source code, etc.

Received on Wednesday, 31 January 2007 07:23:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 14:17:51 UTC