[dsdl-discuss] Part 10 and PSVI: no heart attacks please!

I have had a request that Schematron when using XSLT2 needs to operate
on the PSVI, i.e. the infoset after a document has been XML Schema
validated.

I don't know how XProc handles this, if it does at all.

I suggest that part 10, if it adopts XProc and if XProc doesn't have a
mechanism, should define a dummy
XSD validation process which looks like it is just XML-in/XML-out, but
which actually will be implemented to be XML-in/PSVI-out. An invocation
parameter like "PSVI=true" might indicate whether the process should
just generate normalized XML (e.g. with attribute default values added
etc) or whether it is the typed PSVI in some way. An implementation
would be free to reject PSVI="true" schemas, or to only allow them where
the next process was an XSLT2-based or other PSVI-capable process.

This mirrors reality fairly well, I think: there are XSD validators that
general XML, there are XSLT2 implementations that can use a typed DOM,
but there is no PSVI-in-XML. We originally made the decision in DSDL
to avoid the PSVI route and strictly go XML-in/XML-out. I think that
was the correct design choice, in particular because it makes it easier
for some future implementation to take a cluster of DSDL schemas and
convert them all into a single XSLT file (as best as possible, in the
case of RELAX NG and DTDs, of course) that could be quite efficient.

But the decision not to support PSVI is like the XML WG's "goals", I
think: a good way to avoid a whole set of complicating problems, and a
good way to make sure that we could implement DSDL using standard tools,
where possible. However, now that XSLT2 is becoming more standard,
certainly by the time there are both Microsoft and SAXON
implementations, that consideration need not be so strong. I still think
we should avoid DSDL technologies having any augmented-infoset outputs,
however, I don't see that we need to avoid PSVI input. I think it is
important to have a good XSD co-existence story.

Also, if Schematron gets type binding features, as RELAX NG already has,
it then becomes not only XSD that can feed into a type-aware XSLT2
Schematron process. I think that an advantage of the kind of approach I
am suggesting is that it would only require a paragraph or so to explain
in part 10, but otherwise we could ignore the whole PSVI thing. So it
wouldn't conceptually complicate matters, and it wouldn't be a required
part of DSDL, just an option for part 10 implementations that allow XSD
validation IYSWIM.

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)