[Schematron] errors in iso_dsdl_include.xsl beta
rjelliffe at allette.com.au
Thu Sep 18 00:44:46 EDT 2008
G. Ken Holman wrote:
> At 2008-09-17 01:03 +1000, Rick Jelliffe wrote:
>> There would be no change to existing valid documents.
>> And you would not need to change your code list methodology unless or
>> until it was prudent to take advantage of the new features.
> Them I'm missing something about a "new feature". Inspecting the
> referenced document and doing something different based on its
> content is not a new feature, it is a change in behaviour. If
> someone used my <sch:include> code expecting this "new feature" it
> would not behave as you propose.
Ah, I see what you are saying.
In the particular case where you have two valid schemas, and you want to
a particular element from one valid schema into another, then this
extension will indeed break
things. You are quite correct. I had been assuming that the included
schema would have
been written specifically to just have the elements required: in other
words, that this was
a tool for splitting out a schema into library modules and reuse the
modules (i.e. that you write
the subschemas to suit the inclusion mechanism), rather than a tool for
pieces from other schemas (where you have independent schemas written
without regard to
modularization in that way.)
The original name for <include> was <library> and I need to get away
from that idea.
So I will remove that behaviour again and quickly rewrite the drafts I
am sending to Cheju...sigh.
I think merging addresses the requirement of multi-element includes
But in the use case I think you raise, where you want to cherrypick an
existing schema, is the
granularity it provides too coarse? I think it is still an improvement.
Instead of forcing you to
include each assertion in a rule separately, you can merge the
assertion's rule: however, it
Now if we don't regard this as a kind of <include> (a textual operation)
but a merge of all
the children of some nominated element, then really it is a kind of
<extend> in Schematron
terms, just like abstract rules use. Extending <sch:extend> to cope
with external references
is attractive because it operates on the semantic level rather than the
textual, even though it
can be implemented pretty much textually.
> If we constrain the document element of the *imported* Schematron
> fragment to be the parent element of the <sch:import> directive, then
> this can be used to augment an existing set of children of the parent
> element. For example, adding multiple patterns from an imported file
> to the <sch:import> sibling patterns of the importing file.
I think if we extend <extends> rather than <include> we can have our
cake and eat it, without limiting
the structure of imported files, such as the document element.
>> (The other change I am proposing that would break if a new schema ran on
>> an old processor
>> is the sch:pattern/@documents attribute. I think it would be an
>> acceptable cost.)
> Hmmmmmm ... good point about attributes. Would any attributes of the
> document element of the imported file be added to the attributes of
> the parent of the <sch:import> directive?
I don't have an opinion. This goes back to our longstanding problem that
no schema language exists which
tells you whether an element is scoped to its attributes and immediate
text, or to its descendants. This is
critical information for things like SVG. I think we can easily have a
heuristic or policy for specific
XML elements, such as that
get automatically added. I don't know about xml:base...
But I was hoping to avoid things like renaming ids and so on; making
them the business of the
schema writer rather than the developer. This is certainly the approach
that I would take
with namespaces: that it is the job of the schema writer to make sure
that all required namespace
elements are explicit and manageable up at the top level.
> Good ... but we still need the current "reference" implementation out
> there for users. Many of my customers are embracing Schematron and
> are looking for a stable implementation they can rely on.
Yes, people have a mysterious idea that a standard should be implemented
to be real, whereas we
know that implementation only complicates matters. Ideally, for
stability, a standard should never
More information about the Schematron