Comments (7)
AndrewSales
commented on July 17, 2024
@rjelliffe is it worth extending this approach to concrete patterns and rule-sets too?
For ease of maintenance and composing schemas from shared libraries, for example.
from schematron-enhancement-proposals.
rjelliffe
commented on July 17, 2024
I am not sure what the use case would be: so... maybe?
To me, the general use case would be a library of XSD data types, or a
library of address validators: probabky more daratypey things than
structural. It would be neat if we could do the equiv of
import svg library
import dcterms library
It would be wonderful if these could be integrate into package management
or caching systems, so that the implementation looks in a local location
otherwise downloads. What this requires is perhaps that libraries have a
minor and major version number (not in namespaces) and a policy (if you
request library maj.min, then you can use a cached library if same maj and
= min version number.
RICK
Cheers
Rick
…On Tue, 6 Feb. 2024, 20:32 Andrew Sales, ***@***.***> wrote:
@rjelliffe <https://github.com/rjelliffe> is it worth extending this
approach to concrete patterns and rule-sets too?
For ease of maintenance and composing schemas from shared libraries, for
example.
—
Reply to this email directly, view it on GitHub
<#39 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AF65KKK6L6O5KNFBH46JEXLYSH2DVAVCNFSM53A2CIS2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJSHEYTCNBQG43Q>
.
You are receiving this because you were mentioned.Message ID:
***@***.***
com>
from schematron-enhancement-proposals.
dmj
commented on July 17, 2024
I was looking into the potential of a sch:schema/sch:import element that imports global definitions of another schematron. I.e. patterns, phases, diagnostics, properties, name space declarations, variables etc.
A new top-level element for imports rather/complementary to a sch:library allows us to specify all aspects of the importing behavior, i.e. what to do with conflics.
from schematron-enhancement-proposals.
rjelliffe
commented on July 17, 2024
Would it be better to allow the existing sch:import and sch:extends to
allow IDs or fragment identifiers so that you can, e.g. import the named
elements.
Rick
…On Fri, Feb 9, 2024 at 6:54 PM David Maus ***@***.***> wrote:
I was looking into the potential of a sch:schema/sch:import element that
imports global definitions of another schematron. I.e. patterns, phases,
diagnostics, properties, name space declarations, variables etc.
A new top-level element for imports rather/complementary to a sch:library
allows us to specify all aspects of the importing behavior, i.e. what to do
with conflics.
—
Reply to this email directly, view it on GitHub
<#39 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AF65KKKZYEGYPVQG246SUDTYSXI3VAVCNFSM53A2CIS2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJTGU2DONJVGUYA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***
com>
from schematron-enhancement-proposals.
AndrewSales
commented on July 17, 2024
Would it be better to allow the existing sch:import and sch:extends to allow IDs or fragment identifiers so that you can, e.g. import the named elements.
include and extends already do, don't they?
I was looking into the potential of a sch:schema/sch:import element that imports global definitions [...]
@dmj can you raise a separate issue for this? Thanks.
from schematron-enhancement-proposals.
rjelliffe
commented on July 17, 2024
Languages usually make a distinction between* include* and *import*: where
include operations are really just text/tag substitutions and
macro-parameter substitution, while import can potentially trawl through
the semantics of the markup to use declarations of interest. XSD uses this
approach IIRC. Basic *Includes* are easy to implement; *imports* are
harder, especially where they require traversing multiple schema modules or
multiple imports with potentially different overrides.
But, I think, Schematron uses a different distinction: between *include *and
*extends* where the essential difference is that the *include *just pulls
things in, while *extend *pulls things in expecting to vary them in some
well-defined way: e.g. so that if complete schema A imports complete
schema B, then every document that is invalid against B will also be
invalid against A. (I think this is true??) With *include*, I don't
think this kind of relationship needs to be a consideration.
In other words *extends *(=appending extra constraints) is more like
XSD's *restriction
(*i.e. reducing the number of valid documents
*). *
So if you are adding an import mechanism, I think it would be prudent to
1) Err on the side of simplicity of implementation, a good proxy for which
is often "can it be implemented as a pre-processor easily?
2) Consider whether it allows clear(??) understanding in terms of set
operations a la *sch:extends. *
I guess another approach might be
< sch:include href="my-library.sch"
filter="/*/(sch:ns|sch:properties|sch:diagnostics)" />
Rick
…On Sat, Feb 10, 2024 at 10:56 PM Andrew Sales ***@***.***> wrote:
Would it be better to allow the existing sch:import and sch:extends to
allow IDs or fragment identifiers so that you can, e.g. import the named
elements.
include and extends already do, don't they?
I was looking into the potential of a sch:schema/sch:import element that
imports global definitions [...]
@dmj <https://github.com/dmj> can you raise a separate issue for this?
Thanks.
—
Reply to this email directly, view it on GitHub
<#39 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AF65KKPN4NYSXEIJ4U5HISLYS5OAFAVCNFSM53A2CIS2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJTGY4TQNZWGY3Q>
.
You are receiving this because you were mentioned.Message ID:
***@***.***
com>
from schematron-enhancement-proposals.
dmj
commented on July 17, 2024
Would it be better to allow the existing sch:import and sch:extends to allow IDs or fragment identifiers so that you can, e.g. import the named elements. Rick
This would still require a specification of importing items from another ISO schematron. A pattern, rule, assertion etc. may use top-level constructs such as diagnostics, properties, variables, or functions.
I think we could discuss this separately: a. Specify an importing mechanism, i.e. how to make top-level constructs from a different schema available and b. discuss if sch:extends would be a fit or if we need a distinct schematron element.
@AndrewSales Will raise an issue on importing.
from schematron-enhancement-proposals.
Related Issues (20)
- Update XSLT 1.0 URL HOT 1
- Add attribute named e.g. 'severity' to schematron with well defined semantics for reporting severity levels HOT 8
- pattern/@documents: rules apply only to subordinate documents? HOT 3
- pattern/@documents: pattern variables in scope? HOT 6
- pattern/@documents: definition of behaviour HOT 1
- Defining namespaces HOT 5
- pattern/@document should allow variable that is a document HOT 1
- Ability for role value to be dynamic or different per phase HOT 9
- ISO Schematron iso-schematron.rng license issue HOT 9
- Define the process of importing (include,extending, etc.) definitions from an external ISO Schematron schema HOT 3
- Overrides on sch:include[@href] & sch:extends[@href]
- Clarify ordering of certain elements HOT 1
- SVRL element for compilation and runtime errors HOT 6
- Clarify support for XPath 4.0 or XSLT/XQuery 4.0 HOT 3
- Enhancement for sch:phase - @when HOT 10
- Enhancement for sch:phase - @start-at
- Add postconditions for variables and contexts: @post-condition HOT 13
- sch:pattern/@documents="#SVRL" to allow marking/grading/summarization on patterns in validation results
- Checking for substrings of the node values HOT 12
- Proposal for sch:view element, and Schematron View Vocabulary, for embedded notations, branches, richer iteration (updated @view-as proposal)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from schematron-enhancement-proposals.