Re: proposal to have sequential / grouped messages in soap output

Hello, Henri.

> In the mean time, I designed and deployed a format that specifically 
> matches the Validator.nu internals well:
> http://wiki.whatwg.org/wiki/Validator.nu_XML_Output

I've read through your site but I'd *love* it if you could post an 
example of your format.  As far as I can tell, your validator's output 
does not have a 1-to-1 correlation with the internals of the current 
validator, though.

And would you be suggesting that the w3c validator be converted to a 
more streaming format (no error count summaries)?

> Does the sequential output require a rewrite of client code? If it 
> does anyway, it might make sense to drop the SOAPness and make it 
> plain old XML. Or are clients actually benefiting from the SOAP 
> envelope in terms of tool support in a way that would break with POX?

The sequential format *will* require clients to re-tool.  If the goal is 
to have the SOAP output offer the fullness (and correctness) of the HTML 
output, then it's structure will have to shift away from separating 
"warnings" and "errors" (and also adding "info" and other missing 
content).  The result should be more accurate and offer far more useful 
info than the current format, however

I have no say in the business decision of whether/how to break the 
backwards-compatibility, but I might be willing to help refactor the 
templates to allow a more useful SOAP output format.  Everything I've 
proposed is pretty much at the template level, anyway.  I'm not your guy 
for a validator core re-design, though.


And Oliver, you'd asked for output format proposals...  Based on 
validator's internals, mine would go something like:

  <messages count="4" prevalidationcount="1" errorcount="1" 
warningcount="1" infocount="1">

    <message type="prevalidation" mid="W06" feedbackuri="http://validat...">
      <summary>Unable to Determine Parse Mode!</summary>
      <explanation><![CDATA[...]]></explanation>
      <!-- no source elements or grouping elements with 'pre-val' 
messages -->
    </message>

    <message type="warning" mid="127" feedbackuri="http://validat...">
      <summary>required attribute "ACTION" not specified</summary>
      <groupsummary>required attribute X not specified</groupsummary>
      <explanation><![CDATA[...]]></explanation>
      <source line="58" col="23"><![CDATA[...]]></source>
    </message>

    <message type="error" mid="68" feedbackuri="http://validat...">
      <summary>end tag for "SCRIPT" omitted, but its declaration does 
not permit this</summary>
      <groupsummary>end tag for X omitted, but its declaration does not 
permit this</groupsummary>
      <explanation><![CDATA[...]]></explanation>
      <source line="49" col="5"><![CDATA[...]]></source>
    </message>

    <message type="info" mid="954">
      <summary>start tag was here.</summary>
      <!-- no group summary or feedback uri with 'info' messages -->
      <source line="102" col="8"><![CDATA[...]]></source>
    </message>

  </messages>

It's a little different than yours, Henri (though closer to yours than 
the current SOAP format).  I would still keep the 
<markupvalidationresponse> element encapsulating the <messages> and 
would also keep the meta information like checkedby, validity, doctype, 
etc within it.

POX is cool with me, too.

I still wish I could find a way to do away with the element I'm calling 
<groupsummary>, though.  If there was some way developers could parse 
the standard <summary> text and deduce their own group summary text, 
they could then just use the message id (mid) to define their groupings.

-Chris