Proposal: The correct method for producing a new version of Schem

Proposal for proper language versioning system,about schematron/schematron-enhancement-proposals

AndrewSales commented on July 17, 2024 3

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.

from schematron-enhancement-proposals.

kosek commented on July 17, 2024 1

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.

from schematron-enhancement-proposals.

AndrewSales commented on July 17, 2024 1

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.

what will existing Schematron implementions do for Schematron schemas containing new features in the upcoming version?

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

from schematron-enhancement-proposals.

murata2makoto commented on July 17, 2024 1

I would be uneasy about a mixture of namespaces to represent Schematron structures, if that's what is being suggested

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.

from schematron-enhancement-proposals.

rkottmann commented on July 17, 2024

Would be great if Schematron moves in this direction of using namespaces.

from schematron-enhancement-proposals.

AndrewSales commented on July 17, 2024

I'm not convinced, but I will consult the Working Group.

from schematron-enhancement-proposals.

davidcarlisle commented on July 17, 2024

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.

from schematron-enhancement-proposals.

xatapult commented on July 17, 2024

I concur with David

from schematron-enhancement-proposals.

rjelliffe commented on July 17, 2024

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>

from schematron-enhancement-proposals.

davidcarlisle commented on July 17, 2024

In what way would you have to change "every construct"?

The name of an element is the namespace-localname pair, so by definition, if you change the namespace it is a new element name.
This means that the new version is not an incremental addition with existing elements plus some new ones and perhaps a few removals. Every construct has a new name, there are no elements in common.

I hate default namespaces,

default namespace or prefix, the same issue applies.

A query such as

xmlns:sch ="http://purl.oclc.org/dsdl/schematron "
...
if(sch:*) then 'it's schematron' else ''t's not 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.

from schematron-enhancement-proposals.

murata2makoto commented on July 17, 2024

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.

from schematron-enhancement-proposals.

rjelliffe commented on July 17, 2024

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

from schematron-enhancement-proposals.

rjelliffe commented on July 17, 2024

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

from schematron-enhancement-proposals.

murata2makoto commented on July 17, 2024

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.

from schematron-enhancement-proposals.

dmj commented on July 17, 2024

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.

from schematron-enhancement-proposals.

rjelliffe commented on July 17, 2024

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>

from schematron-enhancement-proposals.

murata2makoto commented on July 17, 2024

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.

from schematron-enhancement-proposals.

rjelliffe commented on July 17, 2024

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>

from schematron-enhancement-proposals.

murata2makoto commented on July 17, 2024

D3 is not impossible if new elements belong to different namespaces.

from schematron-enhancement-proposals.

AndrewSales commented on July 17, 2024

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.

we should prevent existing validators from incorrectly reporting validity without any warnings or errors

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 schema, which could also be included in SVRL output or otherwise reported.

from schematron-enhancement-proposals.

AndrewSales commented on July 17, 2024

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.

from schematron-enhancement-proposals.

rjelliffe commented on July 17, 2024

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>

from schematron-enhancement-proposals.

AndrewSales commented on July 17, 2024

I've gone with schematronEdition in the working draft.

from schematron-enhancement-proposals.

Proposal for proper language versioning system about schematron-enhancement-proposals HOT 23 OPEN

Comments (23)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent