[dsdl-discuss] Re: Selection criteira

Martin Bryan wrote:

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

I think there are various emphaseses from different participants:

   * I think Murata-san's emphasis is on layering well-understood
semantics on top of and under RELAX-NG, and on making sure DSDL
addresses Japanese requirements.

  * I think Martin's emphasis is on business and message validation.

  * I place a high premium on deployment experience rather than
invention, utilizing existing little-languages rather than NIH,
taking advantage of low-hanging fruit with things available
in existing libraries, clarity of use-cases, publishing requirements,
and against feature creep.

  * I think James places emphasis on technical excellence, against
grandiosity and giantism, and in favour of technology a single
developer can implement in a month or two.

What is in commmon with all these approaches is, though James and
Murata-san may differ, a rejection of the W3C XML Schema "we have
to do everything now" approach.

It is interesting that there have been two separate efforts from
XML Schema people for this selection: David Orchard has his
projection work, and I believe that someone (Michael McQueen?)
is presenting some kind of paper on some kind of transformation
mechanism at XML Europe 2004. If these provide substantially
different approaches, and if W3C carries them forward, that frees
us from the requirement of standardizing them ourselves.

So I recommend that the best way forward is to progress part 4
as it has developed; I don't think it is worthwhile either
waiting for the W3C to standardize something or trying to
perfect part 4 if the W3C will then go ahead and do their own
thing. We can add a part 4 bis or a new part when

One way to look at NRL is whether we *need* a more general mechanism,
just to support what we have. Lets look at each part:

  1 - framework: N/A

  2 - RELAX NG: *requires* NRL

  3 - Schematron: NRL is irrelenent because we have our own path
mechanism and handle multiple namespaces

  4 - N/A

  5 - datatypes: we have put the datatypes underneath RELAX NG,
I see no need for some mechanism that goes from candidate
selection directly to datatypes

  6 - path-based integrity constraints: we are waiting for the
right way to do this to become blindingly obvious, or "gathering
use-cases" as it is also known. So we really cannot say whether
NRL is adequate or not.

  7 - Charrep: see Schematron

  8 - Declarative document manipulation: this is the NIST
  architectural forms stuff. This is a non-namespace-based
  selection mechanism: if there are concerns that
  part 4 is dependent on namespaces, I think part 8 is the
  appropriate place for the alternative.

  9 - DTD and namespace-aware DTDs: we don't have a proposal
  so we don't know that NRL does not work OK.

In other words, we have implementation experience with NRL,
RELAX NG needs it, we have part 8 available for non-namespace
based document transformation so we are not closing the
door by accepting NRL for part 4, and other parts don't need
anything more than NRL.

Are there some concrete use-cases where we need something
more than NRL? That would be helpful.

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)