[dsdl-discuss] Fw: DSDL thoughts: Expressing the result of validation

The following comments on DSDL have been received from one of the BSI IST/41
committee members.

> [This is prompted by part 0, section 1, "DSDL identifies specifications to
> be performed by a processor that accepts an input document and produces
one
> or more validation results."]
>
> What's going to be the physical result of applying DSDL to a document? In
> some cases (part 8, 'Declarative doc manipulation' and part 9 'DTDs +')
the
> process will emit at least a transformed document, I suppose.
>
> These and the other parts will also somehow report the result of the
> validation.
>
> The XML Recommenation in some small way specifies how an XML
implementation
> must/might behave (e.g., fatal errors must be detected and reported to the
> application; violation of validity constraints may 'be reported').
>
> Relax NG (from my quick reading) doesn't even go so far. It says a
> conforming processor simply "must be able to determine" whether a document
> is valid according to the spec. Jing reports this determination using a
> 'classic' command-line tool format, e.g.:
>
> F:\jing\foo.xml:1: error: element "foo" not allowed in this context
>
> Schematron allows the user to write their own messages to be reported when
> rules are broken. The implementations I've seen emit these to the console
> without any location information.
>
> I think it would be useful for the DSDL standard to say something about
how
> the result of validation might (must?) be expressed by all the constituent
> processes, at least syntactically.
>
> Things publishers have wanted to see in validation 'reports' on documents
> are IME,
>
> 1. Physical location information (row/column) about where the validity
> violation 'is'. Unfortunate - but they do. This is another reason to think
> about augmenting the 'source' infoset. (i.e., with information associating
> logical stuctures with their physical location). This is not to exclude
> XPath/XPointer location information too.
>
> 2. An indication of severity. Most QA implementation I've worked on have
> needed this - sometimes publishers want things reported 'for information
> only' (e.g., in one system publishers wanted to have journal articles
> flagged that didn't have a <glossary> - unusual but not necessariy wrong);
> sometimes there's something wrong with the content that's a show-stopper.
>
> 3. Maybe, error codes. This may make it possible to have a #pragma-like
> scheme in the XML for 'turning-off' validation in the source code using
PIs.
>
> <?pragma no-warn='4020'?>
> <foo>Do something here that's normally not allowed, according to
constraint
> #4020</foo>
> <?pragma warn='all'?>
>
> (Actually, nobody has ended up going for this, for fear that suppliers of
> XML will turn off all checking as a first step!)
>
> 4. The message text, obviously.
>
> It would be nice to have a language (Document Processing Report Language?)
> that defined a structure for these sorts of thing. It would be nice to
have
> all the parts of DSDL reporting their validation results consistently in
> this language.
>
> But this may not have a place in DSDL?
>
> - Alex.
>
> ------------------------------------
> Alex Brown
> Technical Director
>
> Griffin Brown Digital Publishing Ltd
> Orwell House
> Cowley Road
> Cambridge
> CB4 0PP
> United Kingdom
>
> Tel +44(1223)425730
> FAX +44(1223)425384
> Web http://www.griffinbrown.co.uk

--
DSDL members discussion list
To unsubscribe, please send a message with the
command  "unsubscribe" to dsdl-discuss-request@dsdl.org
(mailto:dsdl-discuss-request@dsdl.org?Subject=unsubscribe)