[dsdl-discuss] Re: Selection criteira

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?

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.

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.

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.

- Alex.

> -----Original Message-----
> From: Martin Bryan [mailto:martin@is-thought.co.uk]
> Sent: 06 April 2004 09:41
> To: dsdl-discuss@dsdl.org
> Subject: [dsdl-discuss] Selection criteira
>
>
> Was previously misnamed:
> Subject: [dsdl-discuss] Re: SC34 WG1 Amsterdam - Lack of Agenda
>
> It has been renamed for consistency and to reduce the traffic on the
> convenors, etc.
>
> > On Tue, 2004-04-06 at 09:43, Martin Bryan wrote:
> > > Eric
> > >
> > > > > Until we are able of offer a full level of
> functionality we need to
> > > > > remain flexible. Personally I think that there are
> functions in
> XPath
> > > 2.0
> > > > > that are vital for validation.
> > > >
> > > > Which ones?
> > >
> > > Among the many, range, intersect and except. I think the
> ForClause might
> > > also be beneficial in places and would love to be able to
> use quantified
> > > expressions for selection of candidates.
> >
> > Do you mean that part 4 should support these features?
> >
> > Which other parts would be affected (in addition of part 3
> which AFAIK
> > will have provisions for supporting XPath 2.0 as one of its hosting
> > languages)?
> >
> > Note that a full support of XPath 2.0 raises the bar pretty high and
> > would mean both supporting W3C XML Schema and forbidding streamable
> > implementations.
> >
> > That's a decision which should be taken very cautiously IMO.
>
> I'm willing to consider what would make an ideal "Streamable
> XPath 2.0"
> though I'm far from convinced that being streamable is a
> necessary condition
> for validation. Pipelining processes does not require that
> they be streamed.
> I consider pipelines vital, and how they are implemented
> irrelevant. And
> yes, DSDL not only needs to set the bar high, it needs to provide the
> springs to help people jump the bar. If users can't clear the
> hurdles they
> already face then we have failed. If this means we need ot
> support the full
> functionality of XML Schemas (if not their diabolical syntax)
> in some future
> part of the standard so be it.
>
> Martin
>
> --
> 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)
>

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