Christian,

Thanks, that does help. It sounds like it is better to specify options in each function call (e.g., fetch:xml or db:create) instead of relying on SET. By "local" in your message I think you mean local to the function call, not local in the sense of what db:system()/localoptions reports. There's something not quite right about the documentation on options, but I can't yet put my finger on what it is. I know enough to proceed with my work, though, so thanks.

Regards, Amanda

-----Original Message----- From: Christian Grün [mailto:christian.gruen@gmail.com] Sent: Thursday, August 06, 2015 8:21 AM To: Amanda Galtman Amanda.Galtman@mathworks.com Cc: basex-talk@mailman.uni-konstanz.de Subject: Re: [basex-talk] Scope of options set with SET

Hi Amanda,

Our global options have a long history. In the beginning of the project, we assumed it's a good thing to specify all options globally, but it soon turned that this leads to numerous side effects, because operations like retrieving a documents are omnipresent and used in very different contexts.

As a result, newer features in BaseX all require local options, while the global options still apply to doc() for the sake of backward-compatibility. It's true that it would probably make sense to have a global solution for the location catalog files, but in order to avoid new surprises, we would probably need to spend quite some time in analyzing each single option.

Hope this helps, Christian

On Thu, Aug 6, 2015 at 2:08 PM, Amanda Galtman Amanda.Galtman@mathworks.com wrote:

...

Hi,

I’m not sure if the following is a bug or if I misunderstand the scope of options set with SET. Suppose I have

a) A DTD that defines a text entity

b) A catalog file that points to the DTD

c) An XML file with a DOCTYPE line that references the DTD, and XML content that references the text entity

If I do the following in a standalone BaseX session

SET DTD true

SET CATFILE [path to my catalog file...]

xquery fetch:xml([path to my XML file...])

then the text entities are missing, presumably because the catalog or DTD is not being read.

Either of the following works as expected, with the text entities resolved:

xquery fetch:xml([path to my XML file...],map {‘dtd’: true(), ‘catfile’: [path to my catalog file...]})

xquery doc([path to my XML file...])

But why do I have to use the 2nd input in fetch:xml if I used SET in the same session? I thought the SET command would suffice, and the 2nd input argument in fetch:xml was available if I either wanted to override an option I had previously set with SET or did not use SET

previously.

...

Thanks,

Amanda