Re: UniCORN book of specifications

* Jean-Guilhem Rouel wrote:
>http://www.w3.org/QA/2006/obs_framework/

My two cents: If I had software design and Java coding resources, I'd
use them to help improve the various Java-based validation tools, like
Henri Sivonen's Validation service, Relaxed, experimental NVDL imple-
mentations and so on, ideally help some of them to join forces and make
a better combined tool, or I'd take the CSS Validator's parser and re-
place all the individual per-property classes by a schema-based vali-
dation approach, or just make a flexible online RelaxNG Validator that
is less difficult to integrate than the others.

In http://esw.w3.org/topic/MarkupValidator/M12N my focus was on making
a common data model for observations (the 'n' in Acorn and Unicorn is
for "notation", implying information, not action). You write:

  Observers' results can be written in SOAP or EARL. The question is
  which of them would be the best to communicate with the framework?
  SOAP output already exists for some validators, but it is not
  normalized (CSS validator has one, Markup validator has a different
  one). So, will it be possible to have a generic handling of these
  SOAP messages if they are all different? Yves seems to say yes, but
  we don't really understand how because how will the framework know
  the way to handle results? For example, if an observer decides to
  write it's messages in a <msg> tag, and another one in <error>, the
  framework won't probably know how to manage them. So, we think that
  having a "universal" WSDL would be a lot easier, but... When Yves
  returns to work we will talk about that problem with him. 

I indeed don't see how you could write a slick and maintainable frame-
work without a common data model, and consequently still think this is
what should be developed first. After that the tool glue (what you call
"contract specification").

If we had good specifications for both, it should be easy to adapt the
Markup Validator to handle at least the data model part properly so it
can generate output and read input of the desired form (where reading
would probably about as simple as a simple XML::Simple call to get a
hash that's then passed through the various chains we have there), so
it would be easy to dispatch from the Markup Validator to a RelaxNG
validation web service running on the same host, and render the output
of that service instead.

I think this is considerably more valuable than implementing a high
level framework that somehow attempts to combine services not built
for that, specifically if that is written in Java.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Thursday, 18 May 2006 08:39:09 UTC