[dsdl-discuss] Re: A proposal for adding a generic inclusion mechanism to DSDL, for use by NVDL and path-based integrity constraints at least

Martin Bryan wrote:
> Rick
>
> Given that you are proposing that this needs to be functionality
> shared by Schematron, NVDL and DSRL, would it not be more appropriate
> if this data-management function was controlled using XProc or
> whatever we choose for Part 10? I also suspect that the reporting
> functionality should also be a Part 10 function, as is seems to me
> that reporting needs to be done when there is a change in processing,
> rather than when there is a change in state. It seems to be that an
> XInclude is actually a processing boundary, rather than a state
> (stream or tree node) boundary.
It can be a processing boundary sometimes, but when you are considering
link integrity, you need to be able to construct the document at the end
of the link before you can validate that the ultimate node is the kind
of thing you want it to be.

For example, say I have a set of 1,000 DOCBOOK 1.0 documents, and my
schemas are for DOCBOOK 100.0. We assume that there have been some name
changes but no structure changes. Fortunately, I have a DSRL script that
renames from 1.0 to 100.0! Saved by DSRL! or am I...I want to validate
one of the instances, but it has links to 99 other docbook instances. In
order to validate that the links are correct, I need to make sure that
those other 99 instances are also DSRL processed *as well as* the
initial instance with the links. XProc cannot do this reliably, as far
as I can see.

If we do it in XProc, as a preprocess, we have do something like
  1) DSRL process all the documents into a temporary location
  2) Be smart enough with the links when processing them to look in the
correct location. Some rebasing logic may be required, but the URL still
needs be trapped or the non-XProc validator still needs to have more smarts.

The thing is that the validators do not ask their calling environment
(e.g. XProc or NVDL) for fixed-up versions of files. They just look at
the file system. And the links URIs are data values, and so independent
of anything in the schema itself.

Now, it may indeed be that the declarations should be part of the Part
10 data management section. However, they need to implemented as part of
Schematron, NVDL and anything else that can get a document (or
fragment). So the location of where to put declarations is not as
important at the moment to me as whether the use case is something we
should be supporting, and its implementation impacts and alternatives.
For example, it may be that a DSRL-aware Schematron implementation will
first look at some external file that accords to part 10 and use that
information to get documents brought in by some custom dsdl:document()
function in XPath processed by DSRL, rather than having the declarations
inline.

I guess behind this is the idea that perhaps now we need to be (thinking
about) making DSDL into a more cohesive set of languages, where every
part can be composed or combined with every other part.

Cheers
Rick

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