Adding a mechanism for schema composition to ISO Schematron
"Rick Jelliffe" <[email protected]> Tue, 29 Apr 2003 19:39:28 +1000
| Newsgroups | gmane.text.xml.schematron |
|---|---|
| Message-ID | <[email protected]> |
From issues raised on the DSDL list, it seems likely that we will need to add
some kind of <include> statement to Schematron.
I can think of five reasons:
* People have asked for a mechanism for schema composition
* DSDL will probably not provide this, but throws the ball into our court
* The old answer ("Use entities") is not appropriate for DSDL, where there is
probably no DTD, and in any case the entity reference would have to use
some kind of path to get the compents we want
* I am not sure that XInclude does what we want either
* Both <let> and abstract schemas are the kinds of things that are more useful
if declarations can be put into libraries, e.g. datatyping or structure libraries.
One particular issue I am thinking about is how to cope with version-ups
of namespaces. So I have a schema written for namespace1 and I
want to import it for use in namespace2.
So does anyone have any ideas or advice on this? Of course, I want to
maintain the basic constraint that it can be implemented using XSLT.
Among the options I see are
* Include, like RELAX NG. Just plonk the resource at the other end in.
<schema>
<ns prefix="html" url="strict_html">
<include href="slack_html.sch#xpath(//pattern)" />
.. extra patterns ..
</schema>
This is simple, but it would really seem to require that the include
also has XPointer or similar built-in. And it allows an error if the
Xpointer is wrong. A pro is that we could import to any granularity:
rules, patterns or whatever. The included material would use
the new namespaces.
* Import, rather like WXS.
<schema>
<ns prefix="html" url="strict_html">
<include href="slack_html.sch" />
.. extra patterns ..
</schema>
This would just import all the patterns, keys and diagnostics from the URL's resource.
The imported material would use the new namespaces.
I suspect that we would want phases not to be imported, because their names could be
wrong.
* Contextual import. This would allow importing schemas (if at the top level) or, say,
rules (if under a pattern) from an external schema.
* Abstract import. This would only import abstract schemas (and abstract rules?).
* Both include and some kind of import
* Some kind of intrusive schema construction, where we can insert extra
rules into an imported pattern.
<schema>
<ns prefix="html" url="strict_html">
<pattern name="myX"
<rule context="x"><assert test="y" /></rule>
<extend href="slack_html.sch" pattern="originalX" />
</pattern>
</schema>
Input welcome. I need to get on top of this fast.
Cheers
Rick Jelliffe
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf