Murata-san
> Part 4, which is now called NVDL (Namespace-based Validation
> Dispatching Language),
> is *not* for selection but for dispatching. The NVDL dispatcher does:
>
> 1) create sections from an XML document,
> 2) combine sections with <attach> and <unwrap>,
> 3) slightly change combined sections to form validation
> candidates, and
As an aside, does anybody else feel that the requirement that validation
candidates should be well-formed creates more problems than it solves? (yes,
and I know this requirement is of long-standing). In my experience the input
to a validation process is usually an arbitrary collection of
(well-balanced) nodes. In NVDL it seems the selection of well-balanced
validation candidates *is* permitted (i.e., select-by-namespace gives you
potentially non-wf content). What happens if such a selection is dispatched
to (say) Schematron?
> 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?
Or is it the case that (conceptually) a 'dispatching' language like NVDL
will merely indicate to a validator which nodes to include in its validation
process, while passing the whole context over ... ?
> The easiest is 4). Certainly, it should be possible to use Part 10
> from 4). I think that the schema attribute of <validate> elements is
> good enough for this purpose. We only have to reference to Part 10
> schemas (or scripts) with this attribute.
Is there going to be some more certain way of stating which schema language
is being invoked, or is a reader meant to deduce this from naming
conventions, etc?
> I believe that 2) and 3) are very different from what Martin and Alex
> imagine as a selection language. These two steps are the most
> difficult part of Part 4. To clarify these steps, I am trying to
> provide formal semantics.
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!
> Now, it remains to consider 1). This is different from mere
> selection, since sections are required to contain slot nodes.
> If
> sections do not contain slot nodes, we cannot apply 2) or 3) to
> sections.
"A slot node has no additional information; it is merely a placeholder for a
element section" - I'm still not entirely sure what slot nodes are. Is this
condidered from an implementation POV?
> 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.
> 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).
> In other words, I
> think that Part 4 should not try to be a selection language,
> Selection
> mechanisms should be detached from Part 4, unless they are extremely
> simple.
This may be a terminological confusion again, but surely Part 4 *is* a
selection language, since it selects certains nodes for validation by
certain schemas according to their namespace?
- 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)Received on Tue Apr 27 16:08:27 2004
This archive was generated by hypermail 2.1.8 : Fri Dec 03 2004 - 14:00:28 UTC