Making pipelines less procedural -- Re: [dsdl-discuss] Re: Part 10 Scenario

> Eric
>
>>Unfortunately, I haven't found the time that would have been needed to
> carry on this task and the working group has decided to document how
> existing pipeline mechanism could be used as our Validation Management
> rather than to propose something from our own conception and, as far as
> I understand the situation, that disqualifies schemachine as well as
> that disqualifies my two proposals...
>
> Let me kill this myth. If I could come up with a proposal of our own that
> could be sent to ISO I would be happy, provided it met all our needs. The
> problem I have is that unless I come up with a document at our next
> meeting in April, ISO will pull the plug on Part 10. I have proposed that
> we explore the option of using existing pipelining solutions as an
> alternative approach, and am looking for you guys to provide enough
> information for me to put together a discussion document for the April
> meeting that ISO will accept as proof that we are still actively working
> on Part 10. Any alternative solutions would be greatly welcomed, providing
> they can meet the use case put forward in the test scenario.

We need to know in more detail what "too procedural" means.

It may just mean, for example, that the WG didn't want Schemachine's <pass>
to be a top-level element. In which case, it could be re-factored
(i.e. into XPL) as an attribute. (I think it is a bogus concern,
because it hides an organizing structure, and the name "pass" could
be replaced by something deemed declarative like "group". But it is
just syntax.)

What is more important, ultimately, is that some formal semantics can
be made up. It is the formal semantics that will allow cross-optimizations
of the different components, not the DTD of Part 10.

So I suggest that we:
 1) Take XPL

 2) Add Schemachine's dependency control mechanisms as attributes:
      @pass
      @phase
      @error
    *or* (better?)

  2a) Just add to XPL an @depend (IDREF) attribute
   which allows partial ordering/grouping of validators--don't run
   this validator until the validation that it depends on has
   finished and succeeded.

   The naive way to implement this would
   be that all validators run, but the results of dependent validators
   are filtered out if the validator they depend on has produced output.
   So @depend does not necessarily imply multiple sequential processes.

   The more sophisticated way to implement this might be, say,
   that when there is an expensive validator (building a DOM
   for schematron) that depends on a less expensive one
   (RELAX NG), then don't perform the expensive one in parallel
   with the cheap one but wait for the cheap one to produce no
   results.

   (@depend cannot point to a validator later along the same chain.)

 3) Make sure that parameters to the top-level can be passed through
  as parameters to validators

This can be said to be "less procedural" to make the WG happy.
It is an improved Schemachine with a diffierent syntax,
so I would be happy. It might be a minimal change for the XPL
implementers so maybe they would be happy. And if they have a
rough spec already, that would be good for Martin to show ISO.

If they don't have a rough spec, then I could quickly tart up
the schemachine spec to make it more XPL-ish and make that available
as the draft, though expecting to move to XPL next round.

Cheers
Rick Jelliffe

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