[dsdl-discuss] Re: Selection criteira

Eric hi

> On Tue, 2004-04-06 at 11:32, Alex Brown wrote:
> > I think we've got a problem here in that, as originally set
> out, DSDL has
> > Part 4 for 'selection of validation candidates'. Whenever
> (so I thought) we
> > needed to select something then part 4 would provide comprehensive
> > mechanisms for that purpose. I imagined this would be a
> fairly catholic
> > language, perhaps allowing specification of existing and
> future query
> > langauges (XPath, XQuery, etc.) to do the selection.
> >
> > Now NRL is lined-up to be 'part 4', and NRL is not a general purpose
> > selection language but addresses the narrower problem of
> selection (and
> > dispatch) of candidates per Namespace. So what has happened
> to the original
> > idea of having a part specifically 'for' selection in all its forms?
>
> Yes, that's a good point that has been discussed in Philadelphia.

I seem to remeber there was concensus something needed to be done ... but
what?

> > It seems to me now the burden of doing this is being
> shifted to Part 10.
> > Whereas before (so I thought) Part 10 would be a
> coordinating language that
> > *used* the language of part 4 to select and dispatch stuff
> to other parts of
> > DSDL, we now have a model whereby Part 4 will select and
> dispatch candidates
> > per Namespace, Part 10 will select and dispatch candidates for
> > non-Namspace-based selections.
>
> Part 10 allows to plug any transformation language and the
> idea is that
> people can use let say XSLT 1.0, XSLT 2.0, STX or whatever if
> they want
> to dispatch pieces of documents to different schemas in ways
> that part 4
> do not cover.

Which is necessary, good and proper for Part 10. I just don't see why, when
the selection happens to be by Namespace, then the user needs to remember
that another part of DSDL can/must be used for a second tier of dispatching
(or that they needn't have used Part 10 if all their needs are namspacey)
... why the special case?
 
> > It seems a shame to me that while *parts* of the design of
> DSDL are based on
> > gold-standard design principles (RELAX NG ...) the
> *overall* design is in
> > danger of ending up in a state which will be likely to
> strike observers as
> > an accidental mess.
> >
> > It would be fine is we were happy to throw everything
> together and then
> > refactor like crazy, but we're instead pressing individual
> parts forward to
> > standardisation without a clear picture of the whole in
> mind. IMHO this is
> > asking for trouble.
> >
> > I think it is debatable whether DSDL needs or benefits from
> having a purely
> > Namespace-based selection language as one of its parts. I
> don't think there
> > is any benefit in having (different?) dispatching
> mechanisms in different
> > parts of the standard.
>
> At the moment, I don't think we have. At least, I can insure
> that there
> is no dispatching mechanism in part 10 at the moment.

I'm thinking of the <validate> element in NRL vs the corresponding elements
(assert/isValid ?) in Part 10 ...
 
> > I would like to consider as options:
> >
> > - Merging parts 4 & 10 to create a select/dispatch language
> for *all* type
> > of selected candidates (aka DSDL framework)
> >
> > - (variations of above) expanding part 4 to encompass non
> Namespace-based
> > selection and losing Part 10; or expanding part 10 to encompass
> > Namespace-based selection and losing Part 4.
> >
> > - Rolling part 4 back to be more like the original
> 'selection of validation
> > candidates' concept (as outlined above) - i.e., expanding
> its selection
> > language to encompass non-Namespace-based selection tasks
> and removing its
> > dispatching language. Then Part 10 would 'use' Part 4 for selection
> > purposes.
>
> Part 10 is currently both more and less than a selection language.
>
> Its purpose is to provide a language that defines what it means for a
> document to be "valid" or "invalid" in a declarative fashion by
> combining the use of existing transformations and validations tools.

I don't think it's going to be possible always to validate in a way that
gives a boolean result (Schematron messages ...), but yes - Part 10 will
emit a validation result (pref. XML!) of some sort.

> It has no selection mechanism built-in but can use transformations as
> external selection mechanism and can also invoke a part 4 schema as a
> validation.

Yes, and I'm suggesting DSDL *should* have its own fully-featured selection
mechanism that we *could* use (XPath NG?). Part 4 has overlapping
functionality with Part 10 because it has its own selection and dispatching
mechanisms.

> Combinations are possible, such as using a XSLT transformation before
> part 4 to split candidates from a monolithic vocabulary into different
> namespaces so that they can be processed with part 4 (or eventually to
> use part 8 to do so if part 8 supports transformations on namespaces).
>
> Part 10 is like a "make" or "ant" system designed for validation
> purposes only.
>
> It can be seen as the glue needed to keep each of the parts based on
> gold-standard design principles...

As I say, there's nothing particularly wrong with any of the *parts* of
DSDL, it's the combination ... (in general combining two excellent things
doesn't always result in excellence - think of cavaire & cream cakes!)

Maybe it's something wrong with the way multi-part standards are forged,
since people are encouraged, in effect, not to see the wood for the trees
(the pressure is on editors to get *their* part done).

Or maybe it's because DSDL is being written according to a only a vaguely
understood (and undocumented) overall design - nobody knows or agrees what
'the wood' is.

Perhaps DSDL needs something like Topic Maps' 'Reference Model', a
'Validation Model' maybe?

- Alex.

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