Hi -- I'm pretty sure this isn't a thing, but I thought I'd ask. I have a raft of namespace declarations because I'm pulling information out of Open Document documents. I'd like to put all thirty-odd of these declarations in their own file and import that, but I'm pretty sure I can't because that imported module would need its own namespace and this would keep its internal namespace declarations from being in scope for the main module, where I actually want them declared. Is there a way to do this? It's not critical, it's an outbreak of neatness, but it would be a nice neatness. Thanks! Graydon

Hi Christian -- Appreciate the confirmation! Any chance of some syntactic sugar for this in a future BaseX release? The use case is writing a bunch of distinct queries to pull stuff out of complex formats like OOXML or Opendocument; there are many namespaces involved, it's important to have them all defined, and it'd be nice to be able to abstract groups of definitions for re-use across queries. So some way to specify "get that bunch of definitions in the current context" would be nice. (But, admittedly, by no means necessary.) Thanks! Graydon On Sun, Aug 11, 2019 at 8:36 AM Christian Grün <christian.gruen@gmail.com> wrote:

Hi Graydon,

Your assumptions were correct: If namespaces are declared in another module, they will be only valid in the scope of that module, and not in the importing module.

If your local element names are unique, and if you prefer short path expressions, you can always use a wildcard prefix (*:...); but that answer is actually not part of your question anymore ;)

Best Christian

On Fri, Aug 9, 2019 at 9:14 PM Graydon Saunders <graydonish@gmail.com> wrote:

...

Hi --

I'm pretty sure this isn't a thing, but I thought I'd ask.

I have a raft of namespace declarations because I'm pulling information

out of Open Document documents. I'd like to put all thirty-odd of these declarations in their own file and import that, but I'm pretty sure I can't because that imported module would need its own namespace and this would keep its internal namespace declarations from being in scope for the main module, where I actually want them declared.

...

Is there a way to do this? It's not critical, it's an outbreak of

neatness, but it would be a nice neatness.

...

Thanks! Graydon

Hi Christian, Would that allow just prolog header statements (import statements, declarations), or also allow prolog body statements (functions, variables, options, etc.)? Would that include imported schema types from the included modules schema import statements? If it is just a simple string substitution, how do you deal with things like the included modules having their own VersionDecl or ModuleDecl statements, and breaking the order of header and body statements? How do you resolve potential namespace redeclarations and multiple import conflicting/overlapping statements being pulled in? Both Java and Python allow you to specify which statements (classes) to import, so maybe something like: import prolog namespaces a, b, c from "path/to/module.xqm" NOTE: This would be something worth raising on the xpath-ng project. Kind regards, Reece On Sun, 11 Aug 2019 at 19:19, Christian Grün <christian.gruen@gmail.com> wrote:

Hi Graydon,

We could possibly introduce an include statement:

include 'path/to/module.xqm';

In contrast to 'import module', the contents of the addressed file would simply be inserted as string into the original module. The inserted string could contain any other declarations that are allowed in the prolog of a query.

More suggestions are welcome; I would particularly interested if other users would benefit from such an extension as well?

Christian

Graydon Saunders <graydonish@gmail.com> schrieb am So., 11. Aug. 2019, 20:07:

...

Hi Christian --

Appreciate the confirmation!

Any chance of some syntactic sugar for this in a future BaseX release?

The use case is writing a bunch of distinct queries to pull stuff out of complex formats like OOXML or Opendocument; there are many namespaces involved, it's important to have them all defined, and it'd be nice to be able to abstract groups of definitions for re-use across queries. So some way to specify "get that bunch of definitions in the current context" would be nice. (But, admittedly, by no means necessary.)

Thanks! Graydon

On Sun, Aug 11, 2019 at 8:36 AM Christian Grün <christian.gruen@gmail.com> wrote:

...

Hi Graydon,

Your assumptions were correct: If namespaces are declared in another module, they will be only valid in the scope of that module, and not in the importing module.

If your local element names are unique, and if you prefer short path expressions, you can always use a wildcard prefix (*:...); but that answer is actually not part of your question anymore ;)

Best Christian

On Fri, Aug 9, 2019 at 9:14 PM Graydon Saunders <graydonish@gmail.com> wrote:

...

Hi --

I'm pretty sure this isn't a thing, but I thought I'd ask.

I have a raft of namespace declarations because I'm pulling

information out of Open Document documents. I'd like to put all thirty-odd of these declarations in their own file and import that, but I'm pretty sure I can't because that imported module would need its own namespace and this would keep its internal namespace declarations from being in scope for the main module, where I actually want them declared.

...

Is there a way to do this? It's not critical, it's an outbreak of

neatness, but it would be a nice neatness.

...

Thanks! Graydon

Hi Reece, Thanks for your reply; I immediately thought that such an extension would have various effects on external tools, such as your XQuery plugin. And I strongly agree that we should further discuss this on the xpath-ng project if the proposal should gain some momentum, because there are simply too many ways how such an extension could look like (the inclusion could be a replacement in the original query string, which was my original thought, but it could be much more). For now, I am wondering if there are more people around who believe that they would benefit from such a new statement in XQuery? Best regards, Christian On Sun, Aug 11, 2019 at 8:48 PM Reece Dunn <msclrhd@googlemail.com> wrote:

Hi Christian,

Would that allow just prolog header statements (import statements, declarations), or also allow prolog body statements (functions, variables, options, etc.)?

Would that include imported schema types from the included modules schema import statements?

If it is just a simple string substitution, how do you deal with things like the included modules having their own VersionDecl or ModuleDecl statements, and breaking the order of header and body statements?

How do you resolve potential namespace redeclarations and multiple import conflicting/overlapping statements being pulled in?

Both Java and Python allow you to specify which statements (classes) to import, so maybe something like:

import prolog namespaces a, b, c from "path/to/module.xqm"

NOTE: This would be something worth raising on the xpath-ng project.

Kind regards, Reece

On Sun, 11 Aug 2019 at 19:19, Christian Grün <christian.gruen@gmail.com> wrote:

...

Hi Graydon,

We could possibly introduce an include statement:

include 'path/to/module.xqm';

In contrast to 'import module', the contents of the addressed file would simply be inserted as string into the original module. The inserted string could contain any other declarations that are allowed in the prolog of a query.

More suggestions are welcome; I would particularly interested if other users would benefit from such an extension as well?

Christian

Graydon Saunders <graydonish@gmail.com> schrieb am So., 11. Aug. 2019, 20:07:

...

Hi Christian --

Appreciate the confirmation!

Any chance of some syntactic sugar for this in a future BaseX release?

The use case is writing a bunch of distinct queries to pull stuff out of complex formats like OOXML or Opendocument; there are many namespaces involved, it's important to have them all defined, and it'd be nice to be able to abstract groups of definitions for re-use across queries. So some way to specify "get that bunch of definitions in the current context" would be nice. (But, admittedly, by no means necessary.)

Thanks! Graydon

On Sun, Aug 11, 2019 at 8:36 AM Christian Grün <christian.gruen@gmail.com> wrote:

...

Hi Graydon,

Your assumptions were correct: If namespaces are declared in another module, they will be only valid in the scope of that module, and not in the importing module.

If your local element names are unique, and if you prefer short path expressions, you can always use a wildcard prefix (*:...); but that answer is actually not part of your question anymore ;)

Best Christian

On Fri, Aug 9, 2019 at 9:14 PM Graydon Saunders <graydonish@gmail.com> wrote:

...

Hi --

I'm pretty sure this isn't a thing, but I thought I'd ask.

I have a raft of namespace declarations because I'm pulling information out of Open Document documents. I'd like to put all thirty-odd of these declarations in their own file and import that, but I'm pretty sure I can't because that imported module would need its own namespace and this would keep its internal namespace declarations from being in scope for the main module, where I actually want them declared.

Is there a way to do this? It's not critical, it's an outbreak of neatness, but it would be a nice neatness.

Thanks! Graydon