What are we validating and why?

I like the direction of this topic here.

Last year I was trying to get folks in the PDF community to standup a TC to formulize a validation syntax for PDF submissions - using simple XML scripting.

Here's a thumb sketch of the "what" and "why" there. For an NIH project we'd implemented java based PDF validation using iText library of grant submissions. This was all strung together by hand in java - and pretty quickly it was apparent everyone was re-inventing the same wheels - checking page layouts / style / content / titles / page / section totals, against specific submission requirements.

What's more - once you had your little "library" of java methods overlaid on the base iText stuff - then you really wanted to be able to script this to make implementation quick and maintenance easier.

I put together a mini-scripting syntax - and then found out couple of other folks in that iText community also had flavours for their tools and methods too. The challenge then is to align all this in a simple and concise - yet powerful and extensible approach.

Sounds familiar eh? Certainly I can point to CAM syntax compared to XSD say in this context ; -)

So - if part of what we're after here is developing that big picture of requirements for a functional scripting that makes page content checking a snap - hell yeah - we need that!

-------- Original Message --------
Subject: Re: [oiic-formation-discuss] Welcome!
From: "Dave Pawson" <dave.pawson@gmail.com>
Date: Fri, June 06, 2008 1:56 am
To: oiic-formation-discuss@lists.oasis-open.org

2008/6/5 David RR Webber (XML) <david@drrw.info>:
> Rob,
>
> For me this is the difference between a schema based approach - and tools
> like Examplotron and CAM.

I'm interpreting Robs response as fairly clear. the 'multiple steps' validation
is needed. In fact quite a few pieces will need stringing together.
No way that a grammar based approach can validate an instance
against the spec.

The only 'odd man out' is the pair of implementations comparison
in visual terms. Not sure if this is included (even if required!). I'm
less sure how it might be done, since ODF isn't a page description
language.

I'd propose that the outcome of this group is a meta test requirement?
The eventual document will be a test requirement indicating what needs
to be tested; this groups output should clearly state what tests need
to be included?
Clearly remaining in the 'what' domain, rather than the 'how'.

regards

--
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk

---------------------------------------------------------------------
To unsubscribe, e-mail: oiic-formation-discuss-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: oiic-formation-discuss-help@lists.oasis-open.org

oiic-formation-discuss message