Saxon

Legacy ID: #4780320 Legacy Poster: Michael Kay (mhkay)

I can't think of an easy solution to this one. Accepting anything like #line would seem to be a non-conformance with the spec and would make queries non-portable. "declare option" is allowed only in very restricted circumstances. I guess the best approach would be to accept input from a LineNumberReader, allowing you to subclass LineNumberReader and invent your own line numbers. If only XQuery used real XML syntax this kind of thing would be so much easier... The other possibility is back-mapping the error locations. If you write your own ErrorListener then you can translate the location information by adjusting line numbers. At the moment, that seems the most promising approach.

Legacy ID: #4780658 Legacy Poster: Chapman Flack (jcflack)

I had just begun gravitating toward the ErrorListener idea myself, so it's good to get a concurring opinion. Thanks. -Chap > If only XQuery used real XML syntax this kind of thing would be so much easier... Ah, but if it used real XML syntax I'd go crosseyed trying to write it. Angle brackets just all begin to look the same after a while... I don't mind saying it, I really like XQuery syntax.

Legacy ID: #4780689 Legacy Poster: Chapman Flack (jcflack)

Ok, I only want my ErrorListener to adjust line numbers in SourceLocators that come from the modified main query, but leave alone any line numbers from imported modules etc. The way my app currently starts up is with its own subclass of Query that overrides makeConfiguration and ultimately calls doQuery with transformed arguments. I didn't come up with any better way to accomplish the query editing than to duplicate the code that resolves the main query argument (-, file, URL, or {string}) and then plants the edited one back in the argument list (always as a {string}). This loses the systemID-- which looks a little sloppy and also doesn't help me identify the SourceLocators that I have to translate. There doesn't seem to be any nice entry point where a subclass of Query could supply its own StreamSource (or whatever) for the query text but continue to enjoy doQuery's parsing of all the documented command-line options. Hmm, maybe if I implement a ModuleURIResolver that recognizes a magic: URL scheme, put that URL on the command line in place of the query and supply the edited query through the resolver... then I could give it a recognizable systemID. Have I overlooked anything less roundabout? -Chap

Legacy ID: #4780708 Legacy Poster: Michael Kay (mhkay)

I would have thought you could override Query.compileQuery() to set a baseURI in the staticEnv object and then call super.compileQuery(); you can then recognize this as the systemId in the error location. In the long term though you may be better off defining your own command line interface and reusing what you need from net.sf.saxon.Query by cut-and-paste rather than trying to subclass it: you'll end up with something that you have more control over. Michael Kay http://www.saxonica.com/

Legacy ID: #4785488 Legacy Poster: Chapman Flack (jcflack)

Ah. Yes ... my subclassing code began life with 8.9, before compileQuery() was factored out into its own method. I see that I could use that now. I'm trying to avoid cut-and-paste duplication as much as possible, because one of my concrete goals is to be able to document my tool in the words "works exactly like net.sf.saxon.Query but with the following namespaces predefined for you." Is it simple to do module imports and namespace declarations entirely by API calls on the static environment? If so, then by overriding compileQuery it might be practical to get the effect I want without text-editing the user's query at all, and then all line-numbering complications would vanish. All the same, I've looked a bit more into the 'extension expression' syntax and it looks like one might do no violence to the spec by inventing a pragma like (# saxon:line 42 'http://www.example.com/myquery.xq' #) { here is the text of the original query } as the semantics are that any processor ignorant of the pragma simply takes the expression in braces anyway, and saxon could use the expression but number its lines beginning with 42 and give it the specified system ID. Nothing urgent, as I see other ways to get where I want, but there are always interesting uses for automated generation or transformation of program text, so a pragma of that sort would never go out of fashion. -Chap

Legacy ID: #4785734 Legacy Poster: Michael Kay (mhkay)

The trouble about using pragmas is that they can only be wrapped around an expression; your code would have to do a lot of parsing the query to discover which parts are expressions and which other things, such as function declarations. You can easily declare extra namespaces using the Java API, but I don't believe you can import modules - module imports are not part of the static context in quite the same way.