[dsdl-discuss] Re: Selection and Dispatching are different

Alex Brown wrote:

>As an aside, does anybody else feel that the requirement that validation
>candidates should be well-formed creates more problems than it solves?
>
I haven't seen any reason to think this.

>>4) invoke validators for validation candidates
>>
>>
>
>Something that troubles me is the question of how much XML the validator can
>'see'.
>
>1. If the schema is invoked on *just* the candidate, what happens if the
>schema contains co-location rules for structures outside the selection. Or
>are we saying that a schema written 'for' a namespace can have no knowledge
>of content outside that namespace?
>
>
>2. How does the validator emit meanigful contextual validation information
>if it doesn't know the context in which the validation candidate occurs?
>
>
My mental model is that an implementation would using pipelines of SAX
or StAX streams,
where locator objects would keep the original location. The discipline
of "XML-in, XML-out" means that any mechanism for transmitting the XML
infoset can be used: the most suitable
one can be used. Actually using XML between stages is probably the
worst method for
implementation, for the reasons you point out; but by not going beyond
XML, we do not
require DSDL APIs--compare this with XML Schemas.

>During discussions in Amsterdam in became clear on occasion that terminology
>can be a problem when discussing DSDL. I agree that dispatching, selection
>(and querying) and all different things!
>
>
So the distinction needs to be clear in the Terms and Definitions section.

>>At present, 1) uses namespace-based selection (i.e., <namespace
>>ns="..."> or <anyNamespace>) followed by the introduction of slot
>>nodes. However, there are no reasons to exclude other selection
>>mechanisms. In fact, somebody said to me that he wants to create
>>sections for subtrees rooted by particular elements such as <table>.
>>This use case requires tag-name-or-attribute-name-based selection. It
>>might be useful to add this feature before Part 4 becomes an IS.
>>
>>
>
>Do that, and part 4 moves even closer to part 10 as a general-purpose
>selection and dispatch language.
>
I am not keen on modes at all. Would allowing tag-names reduce the
requirement for
modes?

>
>
>
>>More sophisticated selection mechanisms (such as XPath) might be
>>required for creating sections. I think that such an extension should
>>be done by *borrowing* selection mechanisms from other specs and that
>>we should not try to stretch Part 4 any further.
>>
>>
>
>DSDL is meant to have a selection language (originally part 4!). Why not
>have the option to choose which 'selection language' to use (as for
>Schematron)? XPath 1.0 has the merit of being familiar (I notice XPath
>classes are included in JDK 1.5 standard libs).
>
>
"Framework-itus" sank SGML. I put that feature into Schematron because
that is the way
people use it, and because the advant of XSLT 2 and XQuery makes it
prudent to avoid
tieing into a single language. We need each DSDL to be small enough
that it can be
understood, implemented, described and reasoned about very simply.

I think NVDL should be targetted to address RELAX NG's specific
limitations, not
to be itself a framework within the ISO DSDL framework.

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)