[dsdl-discuss] Re: Some thougts on Part 10

Innovimax SARL wrote:
> * Entities : we need to have a clear story about them, because infoset
> let them on the floor and the only way to tackle with them is at XML
> level with DOCTYPE-tricky-stuff
I think our story might be
  1) DSRL is supposed to handle unexpanded entity reference remapping
  2) Part 10 may have to also define a kind of null process, which just
  reads in any XML/SGML document in and writes it out with entities
  expanded.
> * Mapping of namespaces/entities : we need a consistent story on
> defining how in *all* DSDL do we handle this kind of mapping (i'm
> thinking especially for DSRL and NVDL)
Unless you are suggesting some standard set of invocation parameters for
processors of individual parts, I think mapping of namespaces and entities
is the business of NVDL and DSRL and OASIS Catalogs. In the case
of entities, our model has never been (I think) that we would preserve
entity references intact.
> * Validation process : how do we define the stages needed for
> validation (for all the languages à-la-EARL, only for DSDL's
> à-la-SVRL) ? do we need to have a simple construct for conditionnal
> validation (on presence/absence of PI/attributes/elements/doctype) ?
> Validation of *set* of documents ? Validation of sequence of documents
> ?
I think EARL is good for the container for individual validation reports,
but I don't see it has value compared to SVRL for individual reports. I
guess
I should check whether SVRL can have an RDF schema.

For conditional validation, another thing to be aware of is that Schematron
can be used to "score" or "grade" validation reports, such as SVRL
validation.
So all that is needed for conditionals is a simple XPath, because complex
scoring can be done using Schematron.
> The other clear use cases are NVDL of course and pipeline
> transformations, but the fact that validation appears sooner than
> transformation makes it a bit trickier and need from us to provide a
> strong basis that infoset seems to miss.
I would start off by just designing a DSDL Validation Report Language, which
would just be the simplest possible profile of EARL, just a simple statement
that a file with a certain name was validated on a certain date as
"valid" or "invalid"
and then have a section for specific reports. I'd try the simplest EARL
possible
first, then only adopt more or EARL as there is some use.

> Other ideas "en vrac" :
> * I also am inclined to propose to add optional *simple* checksum to
> remember the result of the validation.
Like a 0 or 1 for each process in an XProc? (There are some people who
don't like
bitfields or using non-symbolic formats.)

Cheers
Rick

--
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)