Proposal for proper language versioning system #42
Comments
|
Would be great if Schematron moves in this direction of using namespaces. |
|
I'm not convinced, but I will consult the Working Group. |
|
As a general rule I don't think namespaces work well for versioning. If you change the namespace you have changed the name of every construct in the language so it's essentially a new language not an incremental version. No existing elements remain and any existing xpath or xslt acting on schematron documents will just see the files as not schematron. Note xslt, mathml, svg, xhtml etc all have had multiple versions all using the same namespace for essentially this reason. |
|
I concur with David |
|
In what way would you have to change "every construct"?
I hate default namespaces, I admit it: "manifest" markup has proven itself.
And I think that allowing namesoace declaration on any element prevents
useful random-access approaches (as does CDATA sections: you cannot parse
backwards to find a sync point.)
But... perhaps a reason namespaces were so inapproporiate for versioning
was because the tools didn't support it adequately. Which maybe they could
or should: newbies expect it. If Schematron had a map element that say
"ns.2 is ns.1 with the following patterns or rules replaced" that might be
helpful. There might even be a case to be made that, if XML's feature-set
has indeed fossilized then the way to get progress is to provide *more*
flexible processing of its horrible parts, such as namespaces.
I guess one if the approaches would be to put more things into variables
that could be overwritten:
<sch:let name="inline-elements" as="xs:NMTOKEN*"
select="(i b s u a tt br span)" />
So validation would assert that every child with mixed content only had
elements in that list. An upgrade to the schema might only need to override
that variable.
Obviously, these kinds of facilities combine: you make your old ns.1 schema
into a library and pull it in with the namespace mapping and
this kind of constant overriding.
RICK
…On Tue, 6 Feb. 2024, 22:56 Erik Siegel, ***@***.***> wrote:
I concur with David
—
Reply to this email directly, view it on GitHub
<#42 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AF65KKLA2WKUY54J43VQICTYSIK7PAVCNFSM53GD5QQKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJSHEZTMNJQGIZA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***
com>
|
The name of an element is the namespace-localname pair, so by definition, if you change the namespace it is a new element name.
default namespace or prefix, the same issue applies. A query such as xmlns:sch ="http://purl.oclc.org/dsdl/schematron " will report new files as not schematron, of if you edit it to change the namespace it will report old ones are not schematron. You could of course test for either namespace just as you could test for a file being schematron or svg, the two vocabularies would be distinct languages with nothing in common. |
|
I think that namespace should be changed only if semantics of an existing element changes in the new version. Namespace change in such case will prevent misinterpretation of schema by an older implementation. But changing namespace only because of a new version that adds few new minor functions would only confuse users. |
|
Changing namespaces is useful for preventing old applications from providing incorrect results for data conforming to newer versions. RELAX NG and CREPDL did change their namespaces for this reason. |
|
I can see that this approach works where a significant break with previous versions needs to be signalled. It has been used in the move from pre-ISO Schematron to ISO Schematron or DocBook 4.5 to 5.0, but I do not see a strong use case this time for Schematron. Changing the namespace in the next edition of the standard would invalidate all extant Schematron schemas. The task of updating the namespace may become non-trivial for users whose schemas are built from many (often re-used) components, for example. I would not rule it out in future, but I think for now the XSLT-style approach (one namespace across versions) is preferable. |
|
Andrew wrote "*Changing the namespace in the next edition of the standard
would invalidate all extant Schematron schemas. The task of updating the
namespace may become non-trivial for users whose schemas are built from
many (often re-used) components.*"
Yes, but why should the old namespace need to go away? New systems could
accept the old namespace and the new namespace.
*MODEL*
Without the details being important, lets say we reserve four URIs:
http://purl.oclc.org/dsdl/schematron/2025
http://purl.oclc.org/dsdl/schematron/2015 (for identification not use)
http://purl.oclc.org/dsdl/schematron/2005 (not identification not use)
http://purl.oclc.org/dsdl/schematron
where
- a later is a strict superset of the previous (backwards
compatibility), and
- the dateless default means "whatever the implementation handles" (i.e.
unmanaged)
This model gives
- backwards compatability: no existing software or schema or library is
superseded
- limited forwards-compatability: if the pre-processor is added, then
new-namespace schemas can be used on retro-fitted old systems provided they
don't use new features.
*OLD SCHEMAS ON NEW SYSTEM*
Lets imagine a new system built to handle
http://purl.oclc.org/dsdl/schematron/2025. A trivial transform run as part
of the pre-processor stage, so that imported files as well as the main file
all use the expected namespace. There is no complication for any subsequent
schematron->xslt conversion, as the namespaces go away.
<!-- Upgrade namespace -->
<xsl:template match="*" mode="versioning" >
<xsl:choose>
<xsl:when test="
starts-with(namespace-uri(), '
http://purl.oclc.org/dsdl/schematron')">
<xsl:element name="{local-name()}"
namespace="http://purl.oclc.org/dsdl/schematron/2025">
<xsl:copy-of select="@*/>
<xsl:apply-templates mode="versioning"/>
</xsl:element>
</xsl:when>
<xsl:otherwise>
<xsl:copy>
<xsl:copy-of select="@*/>
<xsl:apply-templates mode="versioning"/>
</xsl:copy>
</xsl:otherwise>
<xsl:choose>
*NEW SCHEMAS ON OLD SYSTEMS*
To be more concrete, lets imagine a schema pre-processor stage that lets an
existing implemention run mixes of current namespace and new namespace
schemas (as long as they don't use new features):
<!-- Generify namespace -->
<xsl:template match="*" mode="unversioning" >
<xsl:choose>
<xsl:when test="
namespace-uri()= 'http://purl.oclc.org/dsdl/schematron/2025'">
<xsl:element name="{local-name()}"
namespace="http://purl.oclc.org/dsdl/schematron">
<xsl:copy-of select="@*/>
<xsl:apply-templates mode="unversioning"/>
</xsl:element>
</xsl:when>
<xsl:otherwise>
<xsl:copy>
<xsl:copy-of select="@*/>
<xsl:apply-templates mode="versioning"/>
</xsl:copy>
</xsl:otherwise>
<xsl:choose>
This would be run as part of the pre-processor stage, so that imported
files as well as the main file is converted.
*BUCKETS*
If we think of changes as each belonging to one of four buckets:
- changes that relate to source text management and assembly such as
versioning, documentation, library and namespace
- changes that relate to schema object abstraction: abstract schemas,
phases, variables etc.
- changes that relate to validation
- changes that relate to validation reporting
then I am suggesting that we treat namespaces as belonging to that first
notional bucket (i.e. handled by macro-ish/text processing), and not as if
they had some deeper significance that must invade the subsequent buckets.
(Can buckets be invaded? YGWIM)
Cheers
Rick
…On Thu, Feb 8, 2024 at 5:54 AM Andrew Sales ***@***.***> wrote:
I can see that this approach works where a significant break with previous
versions needs to be signalled. It has been used in the move from pre-ISO
Schematron to ISO Schematron or DocBook 4.5 to 5.0, but I do not see a
strong use case this time for Schematron.
Changing the namespace in the next edition of the standard would
invalidate all extant Schematron schemas. The task of updating the
namespace may become non-trivial for users whose schemas are built from
many (often re-used) components.
I would not rule it out in future, but I think for now the XSLT-style
approach (one namespace across versions) is preferable.
—
Reply to this email directly, view it on GitHub
<#42 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AF65KKKW2YH2Z4AK23QRYW3YSPEWDAVCNFSM53GD5QQKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJTGI3DOMZUGQ3A>
.
You are receiving this because you authored the thread.Message ID:
***@***.***
com>
|
|
Here is previous email with delimiters adjusted for dumb mail software that
strips it:
Andrew wrote "*Changing the namespace in the next edition of the standard
would invalidate all extant Schematron schemas. The task of updating the
namespace may become non-trivial for users whose schemas are built from
many (often re-used) components.*"
Yes, but why should the old namespace need to go away? New systems could
accept the old namespace and the new namespace.
*MODEL*
Without the details being important, lets say we reserve four URIs:
http://purl.oclc.org/dsdl/schematron/2025
http://purl.oclc.org/dsdl/schematron/2015 (for identification not use)
http://purl.oclc.org/dsdl/schematron/2005 (not identification not use)
http://purl.oclc.org/dsdl/schematron
where
- a later is a strict superset of the previous (backwards
compatibility), and
- the dateless default means "whatever the implementation handles" (i.e.
unmanaged)
This model gives
- backwards compatability: no existing software or schema or library is
superseded
- limited forwards-compatability: if the pre-processor is added, then
new-namespace schemas can be used on retro-fitted old systems provided they
don't use new features.
*OLD SCHEMAS ON NEW SYSTEM*
Lets imagine a new system built to handle
http://purl.oclc.org/dsdl/schematron/2025. A trivial transform run as part
of the pre-processor stage, so that imported files as well as the main file
all use the expected namespace. There is no complication for any subsequent
schematron->xslt conversion, as the namespaces go away.
< !-- Upgrade namespace -->
< xsl:template match="*" mode="versioning" >
< xsl:choose>
< xsl:when test="
starts-with(namespace-uri(), '
http://purl.oclc.org/dsdl/schematron')">
< xsl:element name="{local-name()}"
namespace="http://purl.oclc.org/dsdl/schematron/2025">
< xsl:copy-of select="@*/>
< xsl:apply-templates mode="versioning"/>
< /xsl:element>
< /xsl:when>
< xsl:otherwise>
< xsl:copy>
< xsl:copy-of select="@*/>
< xsl:apply-templates mode="versioning"/>
< /xsl:copy>
< /xsl:otherwise>
< xsl:choose>
*NEW SCHEMAS ON OLD SYSTEMS*
To be more concrete, lets imagine a schema pre-processor stage that lets an
existing implemention run mixes of current namespace and new namespace
schemas (as long as they don't use new features):
< !-- Generify namespace -->
< xsl:template match="*" mode="unversioning" >
< xsl:choose>
< xsl:when test="
namespace-uri()= 'http://purl.oclc.org/dsdl/schematron/2025'">
< xsl:element name="{local-name()}"
namespace="http://purl.oclc.org/dsdl/schematron">
< xsl:copy-of select="@*/>
< xsl:apply-templates mode="unversioning"/>
< /xsl:element>
< /xsl:when>
< xsl:otherwise>
< xsl:copy>
< xsl:copy-of select="@*/>
< xsl:apply-templates mode="unversioning"/>
< /xsl:copy>
< /xsl:otherwise>
< xsl:choose>
This would be run as part of the pre-processor stage, so that imported
files as well as the main file is converted.
*BUCKETS*
If we think of changes as each belonging to one of four buckets:
- changes that relate to source text management and assembly such as
versioning, documentation, library and namespace
- changes that relate to schema object abstraction: abstract schemas,
phases, variables etc.
- changes that relate to validation
- changes that relate to validation reporting
then I am suggesting that we treat namespaces as belonging to that first
notional bucket (i.e. handled by macro-ish/text processing), and not as if
they had some deeper significance that must invade the subsequent buckets.
(Can buckets be invaded? YGWIM)
Cheers
Rick
On Thu, Feb 8, 2024 at 2:07 PM Rick Jelliffe ***@***.***>
wrote:
… Andrew wrote "*Changing the namespace in the next edition of the
standard would invalidate all extant Schematron schemas. The task of
updating the namespace may become non-trivial for users whose schemas are
built from many (often re-used) components.*"
Yes, but why should the old namespace need to go away? New systems could
accept the old namespace and the new namespace.
*MODEL*
Without the details being important, lets say we reserve four URIs:
http://purl.oclc.org/dsdl/schematron/2025
http://purl.oclc.org/dsdl/schematron/2015 (for identification not use)
http://purl.oclc.org/dsdl/schematron/2005 (not identification not use)
http://purl.oclc.org/dsdl/schematron
where
- a later is a strict superset of the previous (backwards
compatibility), and
- the dateless default means "whatever the implementation handles"
(i.e. unmanaged)
This model gives
- backwards compatability: no existing software or schema or library
is superseded
- limited forwards-compatability: if the pre-processor is added, then
new-namespace schemas can be used on retro-fitted old systems provided they
don't use new features.
*OLD SCHEMAS ON NEW SYSTEM*
Lets imagine a new system built to handle
http://purl.oclc.org/dsdl/schematron/2025. A trivial transform run as
part of the pre-processor stage, so that imported files as well as the main
file all use the expected namespace. There is no complication for any
subsequent schematron->xslt conversion, as the namespaces go away.
<!-- Upgrade namespace -->
<xsl:template match="*" mode="versioning" >
<xsl:choose>
<xsl:when test="
starts-with(namespace-uri(), '
http://purl.oclc.org/dsdl/schematron')">
<xsl:element name="{local-name()}"
namespace="http://purl.oclc.org/dsdl/schematron/2025">
<xsl:copy-of select="@*/>
<xsl:apply-templates mode="versioning"/>
</xsl:element>
</xsl:when>
<xsl:otherwise>
<xsl:copy>
<xsl:copy-of select="@*/>
<xsl:apply-templates mode="versioning"/>
</xsl:copy>
</xsl:otherwise>
<xsl:choose>
*NEW SCHEMAS ON OLD SYSTEMS*
To be more concrete, lets imagine a schema pre-processor stage that lets
an existing implemention run mixes of current namespace and new namespace
schemas (as long as they don't use new features):
<!-- Generify namespace -->
<xsl:template match="*" mode="unversioning" >
<xsl:choose>
<xsl:when test="
namespace-uri()= 'http://purl.oclc.org/dsdl/schematron/2025'">
<xsl:element name="{local-name()}"
namespace="http://purl.oclc.org/dsdl/schematron">
<xsl:copy-of select="@*/>
<xsl:apply-templates mode="unversioning"/>
</xsl:element>
</xsl:when>
<xsl:otherwise>
<xsl:copy>
<xsl:copy-of select="@*/>
<xsl:apply-templates mode="versioning"/>
</xsl:copy>
</xsl:otherwise>
<xsl:choose>
This would be run as part of the pre-processor stage, so that imported
files as well as the main file is converted.
*BUCKETS*
If we think of changes as each belonging to one of four buckets:
- changes that relate to source text management and assembly such as
versioning, documentation, library and namespace
- changes that relate to schema object abstraction: abstract
schemas, phases, variables etc.
- changes that relate to validation
- changes that relate to validation reporting
then I am suggesting that we treat namespaces as belonging to that first
notional bucket (i.e. handled by macro-ish/text processing), and not as if
they had some deeper significance that must invade the subsequent buckets.
(Can buckets be invaded? YGWIM)
Cheers
Rick
On Thu, Feb 8, 2024 at 5:54 AM Andrew Sales ***@***.***>
wrote:
> I can see that this approach works where a significant break with
> previous versions needs to be signalled. It has been used in the move from
> pre-ISO Schematron to ISO Schematron or DocBook 4.5 to 5.0, but I do not
> see a strong use case this time for Schematron.
>
> Changing the namespace in the next edition of the standard would
> invalidate all extant Schematron schemas. The task of updating the
> namespace may become non-trivial for users whose schemas are built from
> many (often re-used) components.
>
> I would not rule it out in future, but I think for now the XSLT-style
> approach (one namespace across versions) is preferable.
>
> —
> Reply to this email directly, view it on GitHub
> <#42 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AF65KKKW2YH2Z4AK23QRYW3YSPEWDAVCNFSM53GD5QQKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJTGI3DOMZUGQ3A>
> .
> You are receiving this because you authored the thread.Message ID:
> ***@***.***
> com>
>
|
AndrewSales
added
proposed
|
Suppose that we do not change the namespace. Then, what will existing Schematron implementions do for Schematron schemas containing new features in the upcoming version? Will they crash? Will they report incorrect results? Without knowing what will happen, I don't think that we can make a reasonable decision. |
Per 7.2 "[a] full-conformance implementation shall be able to determine for any XML document whether it is a correct schema." As an implementer I read this as: Processor should terminate with an error if the document contains unknown element from the ISO Schematron namespace. The requirements of a simple-conformance implementation in 7.1 has changed in the 3rd edition. It now reads: "A simple-conformance implementation shall be able to report for any XML document that it does not conform to the constraints expressed by a given Schematron schema." While in the previous version it read: "A simple-conformance implementation shall be able to report for any XML document that its structure does not conform to that of a valid Schematron schema." I don't know why the definition of a simple-conformance implementation was changed in such a drastic way. If we go with the 2nd edition, then I would also read it as: Terminate with an error if the document contains unknown element from the ISO Schematron namespace. |
|
Because Schematron schemas are open to foreign elements, it has always been
the case that if you made a typo in the Schematron namespace in body
elements there would be no RNC schema-validity error reported, *except* for
the top-level element. I believe this has been perfectly good enough, and I
have never seen it actually happen where the namespace for the top-level
element is correct but for lower-level elements was not correct.
So I think the equivalent policy is appropriate for versioned namespaces
would be appropriate:
- The sch:schema element needs to be in the most recent namespace used
in the schema, to ensure that the schema fails if run on implementations
that only know some previous namespace.
- This is the same as current behaviour if there is a typo in the
top-level namespace
- If someone imports a versioned-namespace module into an
original-namespace schema, and run this on an original-namespace
implementation, the module will have no effect (or generate an
implementation-dependent report) which could make the schema behave against
expectations.
- This is the same as current behaviour if there is a typo in the
namespace of the imported module.
*Simple and full conformance*
I think the difference is this:
1) A simple-conformance implementation just validates an instance document
correctly (and can generate a run-time report if something strange is found
in the relevant parts of the schema during validation, if not before.)
B.t.w. I believe the new "constraints" is better than the old "structure".
2) A full-conformance implementation allows validation of the *schema
document* independent of any instance validation (i.e., whether the XML
document is a "correct Schematron schema"), and this would include checking
the syntax of XPaths by the way. It is an addition to simple conformance.
So, to take the example where a document has two phases A and B, and phase
B activates a pattern that has not been declared (e.g. due to a typo in the
pattern ID):
1) The simple-conformance implementation does not need to report errors in
phase B if validating in phase A: the implementation can simply not
generate code for phase B and never attempt to resolve IDs that phase B
has.
2) The full-conformance implementation should report in some way that phase
B is broken. It is not required to fail with an error, just report: failing
in this case would not be the conforming implementation option, because it
goes against simple conformance where only errors relevant to the actual
need cause the failure of validation.
So the standards defines, for the reporting obligations, two end-points
between the minimum conforming (e.g., runtime, where unused branches are
stripped) and the maximum conforming (e.g., compile-time, where code is
generated even for unused branches): implementations would provide features
somewhere between.
Regards
Rick
…On Thu, Feb 22, 2024 at 5:36 AM David Maus ***@***.***> wrote:
Suppose that we do not change the namespace. Then, what will existing
Schematron implementions do for Schematron schemas containing new features
in the upcoming version? Will they crash? Will they report incorrect
results? Without knowing what will happen, I don't think that we can make a
reasonable decision.
Per 7.2 "[a] full-conformance implementation shall be able to determine
for any XML document whether it is a correct schema." As an implementer I
read this as: Processor should terminate with an error if the document
contains unknown element from the ISO Schematron namespace.
The requirements of a simple-conformance implementation in 7.1 has changed
in the 3rd edition.
It now reads: "A simple-conformance implementation shall be able to report
for any XML document that it does not conform to the constraints expressed
by a given Schematron schema."
While in the previous version it read: "A simple-conformance
implementation shall be able to report for any XML document that its
structure does not conform to that of a valid Schematron schema."
I don't know why the definition of a simple-conformance implementation was
changed in such a drastic way. If we go with the 2nd edition, then I would
also read it as: Terminate with an error if the document contains unknown
element from the ISO Schematron namespace.
—
Reply to this email directly, view it on GitHub
<#42 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AF65KKNG4E5XRWBMFNLHPFDYUY5CFAVCNFSM53GD5QQKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJVG43DMMRXGI2A>
.
You are receiving this because you authored the thread.Message ID:
***@***.***
com>
|
|
I think the change to the definition of simple conformance in 2020 shifts the onus onto the user to provide a valid schema in the first place. It adds a bullet referring to Annex B, the Schematron schema for Schematron schemas, as if to emphasize this.
I think this hinges on backward compatibility. The new features so far have I think only been additive, so a schema valid to the current standard should also be valid to the next edition. It smooths the upgrade path if schema maintainers want to make use of the new features to leave the namespace unchanged. Strictly speaking, there is only one edition of an ISO standard, the latest one, which supersedes all previous editions. So an implementation claiming conformance is either up to date or not. But we could at least say that conformant implementations should (i.e. advised, not required) report nodes in the Schematron namespace that they do not recognize. (By the way, I find the wording "shall be able to report[...]" a little unsatisfactory: mandating the ability to do something is at one remove from the actual doing.) |
|
A schema conforming to the next version may have syntactical constructs not explicitly allowed in the present version. Such constructs are typically unavoidable. I believe that everybody agrees. Suppose that a document is not valid against a schema conforming to the next version. Existing validators conforming to the previous version are not always able to report that the given document is invalid against the schema. This is because existing implementations cannot handle new constructs appropriately. Again, I believe that everybody agrees. However, we should prevent existing validators from incorrectly reporting validity without any warnings or errors. This is a must. Meanwhile, there are some desiderata. They would be very nice. D1: A schema conforming to the present version of ISO Schematron conforms to the next version. D2: A document valid against a schema conforming to the present version is reported as valid even if validation is done by a validator conforming to the next version. D3: A document valid against a schema conforming to the next version is reported as valid even if validation is done by a validator conforming to the previous version. Changing the Schematron namespace destroys D1, D2, and D3, and is thus acceptable only when it is needed for preventing incorrect validity reports. |
|
I suspect D3 is never possible for functional rather than informative
elements.
Also I believe D1 and D2 are possible, as long as we keep the default
namespace and map it to the most recent version of Schematron that the
implementation supports. In other words, the RNC for Schematron defines
1. The new schema using the current namespace only,
2. The new schema where the versioned namespace must be be used for the
top-level sch:schema element, and all other elements are allowed in either
the current ir the versioned namespace.
This can be trivially implemented by a validator that remaps (e.g., using
the DSDL part for namespace mapping) schema elements to a single namespace.
Rick
…On Sun, 25 Feb. 2024, 12:11 MURATA Makoto, ***@***.***> wrote:
A schema conforming to the next version may have syntactical constructs
not explicitly allowed in the present version. Such constructs are
typically unavoidable. I believe that everybody agrees.
Suppose that a document is not valid against a schema conforming to the
next version. Existing validators conforming to the previous version are
not always able to report that the given document is invalid against the
schema. This is because existing implementations cannot handle new
constructs appropriately. Again, I believe that everybody agrees.
However, we should prevent existing validators from incorrectly reporting
validity without any warnings or errors. This is a must.
Meanwhile, there are some desiderata. They would be very nice.
D1: A schema conforming to the present version of ISO Schematron conforms
to the next version.
D2: A document valid against a schema conforming to the present version is
reported as valid even if validation is done by a validator conforming to
the next version.
D3: A document valid against a schema conforming to the next version is
reported as valid even if validation is done by a validator conforming to
the previous version.
Changing the Schematron namespace destroys D1, D2, and D3, and is thus
acceptable only when it is needed for preventing incorrect validity reports.
—
Reply to this email directly, view it on GitHub
<#42 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AF65KKLRLY5ECHSPRSUQEL3YVKFUFAVCNFSM53GD5QQKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJWGI3TONRUHAZQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***
com>
|
|
D3 is not impossible if new elements belong to different namespaces. |
|
I would be uneasy about a mixture of namespaces to represent Schematron structures, if that's what is being suggested - it would likely prove fiddly for users and poses the question what would happen in a putative edition after next, if that added more new things.
Could we effectively invert this, by requiring implementations conformant to the next version to report as much, at user option? Existing validators could not do so, so would not risk being accidentally conformant. The less invasive versioning technique would be a new attribute on element |
I mentioned that possibility just as a theoretical possibility. Here is yet another possibility. Had we allowed validators conforming to the previous version to skip unknown elements in the existing schematron namespace, we could have achieved D3. I am reluctant to introduce a new namespace for the next version of Schematron, and prefer the version attribute. |
|
The gist of the current draft is:
|
AndrewSales
added
2025
|
Would @standardEdition be better?
I suggest that what is being referenced is not which version of Schematron
(e.g., the allowed patterns of elements and attributes in its namespace)
but which edition of the standard: i.e., both Schematron and the Query
Language Bindings.
I.e.,
<sch:schema queryLanguage="xslt3.1" standardEdition="2025" ...
not
<sch:schema queryLanguage="xslt3.1-2025" schematronVersion="2025"
I think it is helpful to maintain the distinction between the language and
the QLBs as far as possible, to keep Schematron itself minimal and to keep
it from merely converging on XSLTn.
Rick
…On Mon, 11 Mar. 2024, 22:14 Andrew Sales, ***@***.***> wrote:
The gist of the current draft is:
- introduce a new attribute, schematronVersion, on root element schema
- it is optional and has a single allowed value, 2025
- implementations must report this attribute and its value or its
absence, at user option.
—
Reply to this email directly, view it on GitHub
<#42 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AF65KKLG7BPYJLZS2NHLANLYXWGYBAVCNFSM53GD5QQKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJYHAYTSNJSGEZA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***
com>
|
|
I've gone with |
Proposal:
The correct method for producing a new version of Schematron with new syntax, is to make a new namespace. This is how the move from Academia Sinica's original Schematon to ISO Schematron was handled. Implementations need a slight tweak to handle it, and then versioning stops being a problem for users.
In particular, I propose
How:*
Schematron implementations including existing ones should move to either:
a) preprocess schema files to convert the namespace to the one they understand, after which their normal error reporting mechanism will report if they know the particular element or attribute.
For example, an existing implementation would test for
:[starts-with(namespace(), "http://purl.oclc.org/dsdl/schematron-")]
and rename such an element to
{http://purl.oclc.org/dsdl/schematron}*
For example, a Schematron 2 implementation would test for
:[starts-with(namespace(), "http://purl.oclc.org/dsdl/schematron")]
and rename such an element to
{http://purl.oclc.org/dsdl/schematron-2}*
For example, a Schematron 3 implementation would test for
:[starts-with(namespace(), "http://purl.oclc.org/dsdl/schematron")]
and rename such an element to
{http://purl.oclc.org/dsdl/schematron-3}*
b) OR have more complex @ match|@ elect expression.
For example, an existing implementation that currently looks for sch:pattern etc. would look for
*:pattern[starts-with(namespace(), "http://purl.oclc.org/dsdl/schematron")]
N.b. the Schematron 3 implementation would also have a test that rejects earlier version schemas marked experimental:
/*:schema[namespace()= "http://purl.oclc.org/dsdl/schematron-2-experimental"]
so that such schemas have a limited life in the wild, like the dinosaurs in Jurassic Park.
What is effect of this?
Why isn't sch:schema/@Version or something good enough?: Once again we can see that XSLT and XSD have lead the way in how to get least bang-per-buck: in this case with namespaces.
So in XSD and XSLT (and most language) even though elements have their standard namespace, that is not enough to match the appropriate processor. So you cannot merely take an element's name and namespace URI and know what it may contain. In other words, information that the namespace is supposed to represent is missing. So you have to have one "standard" system for identifying the general semantics of the element (the namespace) and then another ad hoc mechanism for actually then identifying which schema/features/operations/version is being used.
(N.b. sch:schema/@schemaVersion documents the schema version, not the version of Schematron being used.)
What is the technical reason people have not used namespaces for versions? The reason was because the large corporate (proprietary and open source) infrastructures were not written to cope with versions in namespaces. Originally many people tried, on the expectation that there would be a one-to-one mapping from namespace to schema, but then found that sofware had been hardcoded for a particular namespace. And the desire to do databinding, to automatically convert between objects and XML, added another barrier of complexity. The problem was that the XML Namespaces specification was _under_specified in the area of versions.
Why doesn't that reason apply to Schematron?
Schematron is in a really nice position of having only a few implementations, so it is possible to build this in ahead of when it is needed. E.g. if XslSch and Oxygen etc put it in soon, it is harmless, but will allow a graceful transition to future versions.
Helpful for determining how to implement other solutions:
If this is adopted, then it helps us understand how other changes should be implemented.: any breaking change in semantics must be explicitly and locally marked up.
For example, a new version can add sch:let/@as because that does not change the interpretation of any other element or attribute.
But if we want to alter sch:pattern to act as a ruleset rather than a switch, we must either add some attribute to the sch:pattern or (better) add a new element sch:rule. But we could not use some top-level attribute such as /sch:schema/@patternsAreActuallyRulesets,nor a command-line parameter, nor a different namespace because none of these survive simple cut and pasting, or allow simple inspection.
The text was updated successfully, but these errors were encountered: