Alex, I very much share your concerns
> 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?
Not to be the "be all and end all of Part 4" but to be the first function
provided under the banner of Part 4. I still have the concept of a "set of
selection mechanisms" as being the longer-term goal of Part 4.
> 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.
Not necessarily within Part 10. We still have the possibility of e.g. Part
14 - Content-based selection of validation candidates.
> 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.
Here, here. My concerns exactly.
> 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.
Alternatively we could adopt NRL as Part 4 (1st Edition) and clearly state
that our longer-term goal is an all-encompassing Part 2 (Final Edition):
Selection of validation candidates.
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)Received on Tue Apr 6 11:49:21 2004
This archive was generated by hypermail 2.1.8 : Fri Dec 03 2004 - 14:00:28 UTC