[Schematron] errors in iso_dsdl_include.xsl beta

[Rick Jelliffe]

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 
include just
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 
mix-and-matching useful
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 
without overhead.
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 
    ancestor::*/@xml:space[1]
    ancestor::*/@xml:lang[1]
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
be implemented.

Cheers
Rick Jelliffe