Re: Cannot recover after last error

Hey Michael,

Thanks for your detailed explanations, I understand that this is a design
decision, but let me explain my point of view a bit, below.

2013/9/30 Michael[tm] Smith <mike@w3.org>

> Jaime Iniesta <jaimeiniesta@gmail.com>, 2013-09-29 20:37 +0200:
>
> > Is there a measure of the performance boost we get when working on
> > streaming mode?
>
> No. But regardless, it's not just about the performance.
>
>
OK, just trying to understand the reasons behind this decision.
If you could point me to more information about the benefits of using the
streaming mode, I'd really appreciate it.



> > Is it worth not being able to fully validate many documents?
>
> For case of the service that I maintain, it's worth it for its behavior to
> be fully streaming. For anybody running a separate service, I think it's up
> to them to decide how they'd prefer to run it.
>
> And it's not a matter of the service not being able to "fully validate many
> documents". For all cases where it stops checking the subtree, there is
> always an absolute error in the document that should be corrected. Once
> that
> error is corrected, the user can then revalidate that document and the rest
> of the subtree will be checked. That does not seem to me to be a bad thing.
>

When I say "fully validate a document", I mean "fully validate a document
in a single pass".

>From my point of view as an end user of a paid service that uses
Validator.nu (W3C Validator Suite), this means that I have to pay extra
money for each of these rechecks. As an end user, what I expect is being
reported for all errors found at the document, and if I have to pay several
times to get a full validation report of my document, I find that unfair.

I know that this is a business decision that should be taken by the other
services that are using this validator. I just mention it so that you can
see my point of view, please don't take this as a criticism of this design
decision, which is not.

Let me just suggest that as activating or disabling this streaming mode can
be an important decision when running Validator.nu, it would be great if it
could be configured when launching the validator, or maybe as an option per
request, instead of having to tweak the code internals.


> > I think that, as Validator.nu would be able to validate those documents
> in
> > non-streaming mode, a good solution would be first trying the streaming
> > mode, and, if this particular error happens, retry in non-streaming mode.
>
> I think I'd rather not experiment with changing the behavior of the
> production service in this regard for something I'm not at all convinced
> provides actual net benefits. If someone would like to try it with another
> instance and come back with data to talk about, that'd be great.
>

My previous proposal seems quite complicated now that I re-read it.

I think that being able to disable the streaming mode on the configuration
when the validator is launched, or as an option per request, would be more
flexible and simpler.


> > If Validator.nu can't be fixed
>
> It's not broken and doesn't need to be fixed. It's operating this way by
> design, not by mistake.
>

That's understood, it's a design decision. I'm just trying to bring
attention to the implications of this design decision for the end users of
other services that rely on Validator.nu.


>
> > so it can fully validate documents,
>
> Again, it can fully validate any document. The fact that it may require the
> user to correct some errors and then re-validate it is not a hardship.
>
>
Unless you're charging them every time they need to re-check :)



> > then I think having a clearer error message would help.
>
> If you have specific suggestions for such a message, please let me know.
>
> > Something that would include that it couldn't recover after the last
> > error because of the streaming mode.
>
> OK, I guess I could put something in there like, "Cannot continue after
> last error because it requires non-streaming error recovery."
>

Something like that, or maybe explaining the end user that it's not a
problem on their documents, but an option on the running instance of the
validator.

I mean, I guess most users would read that message, and wonder how could
*they* fix that thing about non-streaming error recovery on their sites.


> > Anyway, just my 2 cents about improving the validator.
>
> Thanks for the feedback and sorry if I've sounded defensive here, but I
> hope you can appreciate that some thought has already gone into this and
> the current behavior is a well-considered decision and there is not broken
> behavior here that needs to be fixed.
>
>
I totally appreciate this, I understand that it's a well thought design
decision, I just think that in the light of 3rd party services using this
validator, it would help if it would be easier to configure this mode.

Thanks!
Jaime