- From: Norman Walsh <ndw@nwalsh.com>
- Date: Wed, 18 Mar 2015 16:23:42 +0000
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <873852xoj5.fsf@nwalsh.com>
Persuant to my action, I added a proposal for a generalized validation
step to issue 135, https://github.com/xproc/specification/issues/135
# Proposal for a generalized validation step
The following declaration is for a generalized validation step. Much
of what follows describes how this step applies to XML validation, but
the actual validation performed is implementation defined. Validation
of JSON data against json-schema would be entirely plausible.
<p:declare-step type="p:validate">
<p:input port="source" primary="true"
content-types="application/octet-stream"/>
<p:input port="schema" sequence="true"
content-types="application/octet-stream"/>
<p:input port="models" sequence="true"
content-types="application/xml */*+xml text/*"/>
<p:output port="result" primary="true" sequence="true"/>
<p:output port="report" sequence="true"/>
<p:output port="validation-attempted" sequence="true"/>
<p:option name="assert-valid" select="'true'" as="xs:boolean"/>
<p:option name="group" select="''" as="xs:string"/>
<p:option name="phase" select="''" as="xs:string"/>
<p:option name="version" as="xs:string"/>
<p:option name="parameters" as="map(xs:QName,item())"/>
</p:declare-step>
The semantics of the `p:validate` step are that the `source` document
is validated in an implementation defined way. The `schema` and
`models` ports exist only to provide suggestions to the
implementation.
There are several possible outputs:
1. If the processor considers that no validation was requested (or
does not recognize or cannot perform the requested validation), or
if the `assert-valid` option was `false` and validation failed,
then the original document is returned on the `result` port.
2. If the processor attempts to validate and succeeds, then the
validated document or documents are returned on the `result` port.
In this case, the `validation-attempted` port should document the
validation or validations that were attempted.
3. If the processor attempts to validate and fails, and the
`assert-valid` option is true, then nothing appears on the output port
and an error is raised.
ISSUE: In the case where this error is caught by `p:catch` (how) can
the `validation-attempted` and `report` steps be read?
The output on the `report` step depends on the validation attempted.
For Schematron validation, a report format is defined. For other kinds
of validation, the report is implementation-defined.
Although the step is for generalized validation, it does have a couple
of options designed to support a specific XML scenario: the XML Model
Processing Instruction. In the absense of other information,
implementations *should* use the XML Model PI to determine what kind
of validation to perform on XML documents.
The `group` and `phase` options provide the corresponding values as
discussed in the XML Model PI spec.
The `models` input port and the `validation-attempted` output port use
XML documents to describe desired validation in the former case and
validations attempted in the latter. The following `c:model` element
definition *should* be supported.
<c:model
href? = anyURI
type? = string
schematypens? = anyURI
charset? = string
title? = string
group? = string
phase? = string
/>
Additional variations on `c:model` are allowed, as are entirely
different vocabulary elements as appropriate.
## Validation with RELAX NG
When RELAX NG validation is selected, the following parameters
*should* be recognized: `dtd-attribute-values`, and
`dtd-id-idref-warnings`.
# Validation with XML Schema
When XML Schema validation is selected, the following parameters
*should* be recognized: `use-location-hints`, `try-namespaces`, and
`mode`.
# Validation with NVDL
If an NVDL schema appears on the `models` port, NVDL validation
*should* be attempted.
Be seeing you,
norm
--
Norman Walsh
Lead Engineer
MarkLogic Corporation
Phone: +1 512 761 6676
www.marklogic.com
Received on Wednesday, 18 March 2015 16:24:33 UTC