Validating (sub)documents by URI reference

[David Rosenborg <david.rosenborg@pantor.com>]

Hi!

 

One feature I would find useful is to be abel to specify a pattern for a resource

identified by a URI in the document being validated. I'm not sure it falls

on the right side of the 80/20 mark though. For example, in the RELAX NG

schema for RELAX NG, there is no formal way to specify that the

resource specified by the URI in the href attribute of an include element

must match the grammar pattern or that the resource identified

by an externalRef element must match the pattern pattern.

 

Of course this is not a problem without a solution: you can always transform

the document before validation and expand the references (like it's done in

the Simplification procedure described for RELAX NG). However, for matters

of convenience and annotation I think it would be valuable if it was possible

to do this in a formal way within RELAX NG it self.

 

So some thoughts from the top of my head:

 

You could implement this using a datatype library:

 

<element name="include">

  <attribute name="href">

    <data type="myURI" datatypeLibrary="http://example.org/myLibrary">

      <param name="relax-ng-pattern-uri">grammar.rng</param>

    </data>

  </attribute>

  ...

</element>

 

Pros:

* Doesn't affect the RELAX NG specification.

 

Cons:

* Implementation dependent whether the particular library is supported or not. Who could standardise such a library? If the

builtin library had a third type 'uri' this could be part of the core spec.

* Forces the referenced pattern to be in a separate file.

 

A more intrusive method would be to add a new pattern element which would be allowed where the data pattern is allowed:

 

<element name="externalRef">

  <attribute name="href">

    <uriRef>

      <ref name="pattern"/>

    </uriRef>

  </attribute>

</element>

 

The constraints on the content of the uriRef would be the same as for the start element.

 

Pros:

* Not implementation dependent

* Simpler to use

* More flexible: can reference pattern in the same file for example.

 

Cons:

* Changes the RELAX NG specification.

 

None of these methods should be particulary hard to add to a RELAX NG processor.

 

Any thoughts?

 

Cheers,

 

</David>

 

David Rosenborg

Pantor Engineering AB