Re: sqf:fixes within sch:pattern

Thanks, Nico, esp. for pointing to the workarounds suggested in the Escali extension. I agree that sch:include is a different kind of animal than many other *:include elements, and effectively limits recursion. I’ll take a look at the es:import method you’ve suggested, and see if it suits the work I’ve been doing.

On a related note, I’m not certain why sqf:fixes exists. Wouldn’t the very placement of a sqf:fix or sqf:group already indicate the scope of the fixes, i.e., whether they are global or local? The relationship of sqf:fixes to sqf:fix seems to evoke hypotheticals like (nonexistent) *xsl:functions to xsl:function, which doesn’t make sense. But there may be design decisions behind introducing sqf:fixes that fall outside my admittedly limited experience.

Best wishes,

jk
--
Joel Kalvesmaki
Editor in Byzantine Studies
Dumbarton Oaks
202 339 6435

From: Nico Kutscherauer <kutscherauer@data2type.de<mailto:kutscherauer@data2type.de>>
Date: Sunday, May 31, 2015 at 9:29 AM
To: "Kalvesmaki, Joel" <KalvesmakiJ@doaks.org<mailto:KalvesmakiJ@doaks.org>>
Cc: "public-quickfix@w3.org<mailto:public-quickfix@w3.org>" <public-quickfix@w3.org<mailto:public-quickfix@w3.org>>
Subject: Re: sqf:fixes within sch:pattern

Hi Joel,

Thank you for the feedback! I understand your problem, but I think the main problem is, that Schematron does not have a useful include method, like XSLT or XSD.

For better packaging and including QuickFixes the sqf:fixes element has an optional id attribute, so the sqf:fixes can be included by reference to this ID (href="document/url#fixes-id" - some Schematron implementation or XInclude support this). But I don't think we should do more, just because the embedding language has some gaps in their functionality. That would be just patchwork on the symptoms and wouldn't fix the real problem.
I would prefer a better include method in Schematron, as I described here: http://www.schematron-quickfix.com/escali_xsm/escali-ext_en.html#sqf:d110e101

If we allow fixes in patterns - I was thinking about that - we shouldn't do it like sch:let variables in Schematron: The fix should be available just in the pattern, where it was declared. That is the common practice in XML languages. But I'm not sure, if we really need this?

Best Regards,
Nico

___________________________________________

Nico Kutscherauer
XML Developer

data2type GmbH
Wieblinger Weg 92a
69123 Heidelberg
Tel.: +49-(0)6221-73 912 65
Fax: +49-(0)6221-73 912 66

www.data2type.de<https://www.dpunkt.de/buecher/3-89864-415-4.html>

Company's head office: Heidelberg
Commercial Register court: AG Mannheim HRB 715195
CEO: Manuel Montero Pineda
___________________________________________

2015-05-27 18:24 GMT+02:00 Kalvesmaki, Joel <KalvesmakiJ@doaks.org<mailto:KalvesmakiJ@doaks.org>>:
Greetings,

Schematron permits global variables to appear as children either of sch:schema or sch:pattern. This flexibility has proved very useful to me, particularly in a project that involves with multiple nesting schematron files. I can declare a global variable within a nesting sch:pattern that may not centrally apply to any sibling nesting sch:patterns (but is nevertheless accessible to those sibling nesters, because any variable under sch:pattern is available to any other sch:pattern), keeping it close at hand for when that module is being edited.

I’d like to request the same allowance be made for sqf:fixes, that they be allowed to be children of sch:pattern. That way a global SQF that applies mainly to a particular module (say a nesting sch:pattern) can be kept within the module, along with the other variables that pertain to that sch:pattern. It’s important, though, to make sure that rules permit any sqf:fixes[parent::sch:pattern] be available to any //sch:pattern, the same way sch:let behaves.

Best wishes,

jk
--
Joel Kalvesmaki
Editor in Byzantine Studies
Dumbarton Oaks
202 339 6435

Received on Tuesday, 2 June 2015 15:45:55 UTC