Revisited: indirect module imports do not work anymore in Saxon 9.7 HE

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Revisited: indirect module imports do not work anymore in Saxon 9.7 HE

Hans-Juergen Rennau
Dear Saxon team,

in earlier posting by Yury Zaytsev reported a bug consisting of a failure to process indirect imports as expectedly (foo imports bar, bar imports foobar, yet bar's invocation of a function in foobar yields an error
Cannot find a matching 1-argument function named ...

The problem occurs when foo, bar and foobar share the same namespace. This was dealt in Bug #2461.

As an end result, the expected processing of indirect imports can only be achieved by using a command-line option --xqueryMultipleModuleImports:on (or changing the corresponding configuration option). The reason given was that the spec would not clearly mandate what to do:

XQuery spec 3.1:
"A module may import its own target namespace (this is interpreted as importing an implementation-defined set of other modules that share its target namespace.)"

But this argment appears to me very questionable. The spec uses equivalent wording when defining the processing of module imports in general:
"Each module import names a target namespace and imports an implementation-defined set of modules that share this target namespace."

So this talking about "implementation-defined sets of modules" is fine from a formal point of view, but should not serve as a justification to ignore the location hints except for compelling reasons. Here again, the spec would sanction such ignoring:
"The URILiterals that follow the at keyword are optional location hints, and can be interpreted or disregarded in an implementation-defined way."

But that's not helpful. My problem with the current state of the Saxon processor is that it ignores location hints, covered by the spec but upsetting to the user. And I cannot see any reason why the ignoring of the hints is less upsetting in the case of indirect imports, compared with any other imports.

Indirect imports within a target namespace are very important in practise. Applications can easily consist of many dozens of modules. To use different namespaces for each one is so unpractical as to be out of the question. So it's normal that many modules share the same target namespace. A solution which requires the user of a module to be aware of other modules directly or indirectly required by the module in question violates the principle of encapsulation, it seems to me, and creates unnecessary complexity.

No haste - but can you ocasionally reconsider the question if in the long run the current behaviour is a good choice?

Thanks you, with kind regards -
Hans-J├╝rgen Renau













------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help 
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Revisited: indirect module imports do not work anymore in Saxon 9.7 HE

Michael Kay
My recommendation would be to use a distinct module namespace for each module. Having multiple modules with the same namespace means you are dependent on location hints to distinguish one module from another, and that makes you excessively dependent on behaviour that is not defined in the spec (or which is explicitly implementation-defined).
 
The problem with a design in which modules are assumed to be distinct if their location hints are distinct is that it's very sensitive to the rules for URI equivalence.
 
I don't see any argument here that changes the original basis for the decision; and any change that we make now to Saxon's behaviour will inevitably cause inconvenience to a proportion of the user base.
 
Michael Kay
Saxonica
 
 
Dear Saxon team,
 
in earlier posting by Yury Zaytsev reported a bug consisting of a failure to process indirect imports as expectedly (foo imports bar, bar imports foobar, yet bar's invocation of a function in foobar yields an error
Cannot find a matching 1-argument function named ...

The problem occurs when foo, bar and foobar share the same namespace. This was dealt in Bug #2461.
 
As an end result, the expected processing of indirect imports can only be achieved by using a command-line option --xqueryMultipleModuleImports:on (or changing the corresponding configuration option). The reason given was that the spec would not clearly mandate what to do:
 
XQuery spec 3.1:
"A module may import its own target namespace (this is interpreted as importing an implementation-defined set of other modules that share its target namespace.)"
 
But this argment appears to me very questionable. The spec uses equivalent wording when defining the processing of module imports in general:
"Each module import names a target namespace and imports an implementation-defined set of modules that share this target namespace."
 
So this talking about "implementation-defined sets of modules" is fine from a formal point of view, but should not serve as a justification to ignore the location hints except for compelling reasons. Here again, the spec would sanction such ignoring:
"The URILiterals that follow the at keyword are optional location hints, and can be interpreted or disregarded in an implementation-defined way."
 
But that's not helpful. My problem with the current state of the Saxon processor is that it ignores location hints, covered by the spec but upsetting to the user. And I cannot see any reason why the ignoring of the hints is less upsetting in the case of indirect imports, compared with any other imports.
 
Indirect imports within a target namespace are very important in practise. Applications can easily consist of many dozens of modules. To use different namespaces for each one is so unpractical as to be out of the question. So it's normal that many modules share the same target namespace. A solution which requires the user of a module to be aware of other modules directly or indirectly required by the module in question violates the principle of encapsulation, it seems to me, and creates unnecessary complexity.
 
No haste - but can you ocasionally reconsider the question if in the long run the current behaviour is a good choice?
 
Thanks you, with kind regards -
Hans-Jürgen Renau
 
 
 
 
 
 
 
 
 
 


	

 


------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help 
Loading...