[Schematron] errors in iso_dsdl_include.xsl beta

G. Ken Holman gkholman at CraneSoftwrights.com
Tue Sep 16 22:53:50 EDT 2008


At 2008-09-17 01:03 +1000, Rick Jelliffe wrote:
>G. Ken Holman wrote:
> > But then you need a different keyword other than sch:include ...
> > perhaps sch:merge ... but I don't think you can arbitrarily change
> > the semantics of sch:include now that it has been out and implemented
> > for a while.
> >
> > I know that my existing and deployed sch:include stylesheets would
> > stop working.
> >
>Why would they stop working?

Because the current <sch:include> functionality brings in the 
document element of the referenced document in place ... it does not 
check to see that the document element of the referenced document is 
the parent element of the <xsl:include> and in finding them the same 
injects only the children of the document element.

>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.

>(Or it is a good thing if schemas that the implementation does not
>understand fail, on the grounds that you don't want false positives?)

Sorry, I'm not sure what you are saying there.

> >> I think this is the neatest way to cover what many people are
> >> requesting.
> >>
> >
> > I guess I missed seeing what people are requesting.  Can you cite
> > some examples?
> >
>Well you for one!

Sorry, Rick, I didn't recognize your proposed functionality as being 
something I requested and we discussed.  I see it now.

>The request has been for a better inclusion
>mechanism, with the specific
>problem with the current include being that it only allows one branch to
>be included, whereas
>people have multiple branches they want, for example multiple patterns
>or multiple assertions.
>(The problem is that IDs only allow single elements to be located, and
>that XPointer's range functionality
>is fundamentally broken because it does not correspond to a WF document.)

Yes, I now recall our discussion on this point, thank you ... that 
<sch:include> can only bring in a single construct.  Honestly, I 
hadn't recognized it when I read it.

>We discussed here whether an include or an import mechanism was needed,
>and IIRC correctly
>people did not get too excited by an import mechanism (at least a
>top-level one.)
>
>I am very keen to see what people think about this merge functionality
>and whether it would
>address the problem they have with the current include. And, of course,
>the option of having
>an element called <merge> (even though otiose) is not crazy, if that is
>what people prefer.
>(I saw another standard use <merge> for its inclusions recently, sorry,
>no reference, so I don't
>think my proposal is unique.)

Well, reading Florent's comment about <sch:import> working by 
indicating the element it is replacing or augmenting, I'm getting 
quite interested in this as a new Schematron construct.  My post was 
more concerned about changing the semantics of <sch:include> than 
discounting the added functionality.

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.

>(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?

> >> The same mechanism also should
> >> work at any level of merge, not just top-level. (Actually, I will have
> >> to get rid of any position dependencies
> >> in the skeleton in order to make top-level merges with namespaces and
> >> phases work.)
> >>
> >
> > Can any proposed functionality be implemented in different modules
> > than the modules put forward as "reference implementations"?
> >
>I will remove the "reference" comment when I move this one out from beta
>status, and I think it is clear
>that the merge functionality is experimental.

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.

Thanks, Rick!

. . . . . . . . . . .  Ken

--
Upcoming XSLT/XSL-FO hands-on courses:      Wellington, NZ 2009-01
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
G. Ken Holman                 mailto:gkholman at CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/s/
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/s/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal





More information about the Schematron mailing list