Defining namespaces

[AndrewSales]

@dmj raised this in his talk about atop at the users meetup last week.

If I understood correctly, the use case is to embed the definition of Schematron constraints in isolation from a complete schema. Without visibility of ns elements, there is no mechanism at hand to define namespaces used by the query language expression.

Possible options here include:

1. Allow ns to occur wherever needed, e.g. as a child of pattern, etc.
2. Allow xmlns pseudo-attributes to declare namespaces, in line with the standard mechanism.
3. Deprecate ns as it is currently defined, but allow its continued usage, for backward compatibility.
4. Remove ns altogether (in favour of e.g. (2) above), removing backward compatibility.

See also https://github.com/AndrewSales/XQS/issues/15.

[rjelliffe]

I don't understand the use-case, and I think it might be based on an erroneous idea.

sch:extends Currently, Schematron does allow you to have external documents containing a pattern and an ns.

When the document is imported using sch:extends, the ns declaration is brought in with it as well as the pattern. What is the problem with sch:extends here?

< sch:schema>
 < !-- this schema fragment gets imported into some other schema using
sch:extends.
      The importing schema gets the sch:ns and the sch:pattern -->
   < sch:ns .../>
   < sch:pattern ...
   < /sch:schema>

Scoping

''Possible options here include:''

1. ''Allow ns to occur wherever needed, e.g. as a child of pattern, etc.''

This goes against scoping.

Standard?

2. ''Allow xmlns pseudo-attributes to declare namespaces, in line with the standard mechanism.''

Please imagine my eyeballs exploding with tears :-) THIS IS NOT THE "STANDARD" MECHANISM!!! NOT NOT NOT NOT NOT

Read the XML Namespace standard: it DOES NOT cover Qnames in context. There is no consistency here in the standards either: indeed XML Schemas uses a different mechanism for Qnames in context (elementFormDefault) than XSLT has. Lets no make up "standard" things out of air.

In fact, XML Schemas 1.1 requires you to specify the default namespace binding for an assertion in an attribute!: @.***, which, complicatedly, allows you to inherit a value from the in-scope namespaces or specify your own URI: xpathDefaultNamespace = (anyURI http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/datatypes.html#anyURI | (##defaultNamespace | ##targetNamespace | ##local)) https://www.w3.org/TR/xmlschema11-1/#cAssertions

This is the kind of complexity that allow default namespaces, and scoped namespaces, creates.

Default namespaces cause severe problems for users (it is the cause of most questions people have about XML) and are broken, in the main. And they are a real implementation headache, because they create an inheritance path that complicates e.g. cut and paste. Schematron's approach of just allowing one place (the top of the current file) where the namespaces are declared, has worked really well.

Also: The sch:ns namespace is data related to the elements and attributes of the document being validated, which can be provided in the SVRL and documentation; the xmls is related to element and attribute names of Schematron or other functional items which would not go into the SVRL or documentation. So, conceptually, they belong to different domains.

Regards Rick

On Thu, Jun 8, 2023 at 1:39 AM Andrew Sales @.***> wrote:

@dmj https://github.com/dmj raised this in talk about atop https://github.com/TEIC/atop at the users meetup last week.

If I understood correctly, the use case is to embed the definition of Schematron constraints in isolation from a complete schema. Without visibility of ns elements, there is no mechanism at hand to define namespaces used by the query language expression.

Possible options here include:

1. Allow ns to occur wherever needed, e.g. as a child of pattern, etc.
2. Allow xmlns pseudo-attributes to declare namespaces, in line with the standard mechanism.
3. Deprecate ns as it is currently defined, but allow its continued usage, for backward compatibility.
4. Remove ns altogether, removing backward compatibility.

See also AndrewSales/XQS#15 https://github.com/AndrewSales/XQS/issues/15 .

— Reply to this email directly, view it on GitHub https://github.com/Schematron/schematron-enhancement-proposals/issues/62, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF65KKNFUYQ7YQNZ674U3GLXKCOB5ANCNFSM6AAAAAAY6B6HW4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[rjelliffe]

The emailer stripped out the name of the attribute that XSD uses: xsd:assert / (at) xpathDefaultNamespace.

Apologies for that. Rick

On Thu, Jun 8, 2023 at 1:39 AM Andrew Sales @.***> wrote:

@dmj https://github.com/dmj raised this in talk about atop https://github.com/TEIC/atop at the users meetup last week.

If I understood correctly, the use case is to embed the definition of Schematron constraints in isolation from a complete schema. Without visibility of ns elements, there is no mechanism at hand to define namespaces used by the query language expression.

Possible options here include:

1. Allow ns to occur wherever needed, e.g. as a child of pattern, etc.
2. Allow xmlns pseudo-attributes to declare namespaces, in line with the standard mechanism.
3. Deprecate ns as it is currently defined, but allow its continued usage, for backward compatibility.
4. Remove ns altogether, removing backward compatibility.

See also AndrewSales/XQS#15 https://github.com/AndrewSales/XQS/issues/15 .

— Reply to this email directly, view it on GitHub https://github.com/Schematron/schematron-enhancement-proposals/issues/62, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF65KKNFUYQ7YQNZ674U3GLXKCOB5ANCNFSM6AAAAAAY6B6HW4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[AndrewSales]

I don't understand the use-case

At which point we should ask the proponents to explain. @dmj , @sydb - do you have any comment here?

[dmj]

I think I was mistaken and there is no need to change a thing: Global namespace bindings via sch:ns are just fine, a ISO Schematron processor just has to turn them into xmlns-namespace bindings early on when including external references.

It would be helpful if the specification would explain what a user of ISO Schematron should expect to work and what not. I.e. wether namespaces bound by sch:ns should carry over when a schema fragment is included.

Example:

Schema A

  <schema xmlns="http://purl.oclc.org/dsdl/schematron" queryBinding="xslt2">
    <ns prefix="ex" uri="http://example.com/ns"
    <pattern>
      <rule context="ex:parent">
        <extends href="schema-b.sch#target"/>
        <assert test="count(ex:child) gt 1"/>
      </rule>
    </pattern>
  </schema>

Schema B

  <schema xmlns="http://purl.oclc.org/dsdl/schematron" queryBinding="xslt2">
    <ns prefix="ex" uri="http://example.com/other-ns"/>
    <pattern>
      <rule  xml:id="target" abstract="true">
        <assert test="exists(ex:title)"/>
      </rule>
    </pattern>
  </schema>

I think it would be reasonable to expect the included assertion tests for a title element in the http://example.com/other-ns namespace, not a title element in the http://example.com/other-ns namespace.

[dmj]

On the other hand: The problem we face with ATOP is that we want to compose a ISO Schematron schema from rules and patterns defined in different documents, from different people in different times. The xmlns pseudo attribute allows us to preserve all the namespace bindings and assemble a complete ISO Schematron schema.

I can't see a way we can achieve this with the sch:ns elements without renaming prefixes, which in turn means parsing the XPath expressions.