Re: TMQL - Proposal for a %base directive

Hi Lars,

On 4 May 2011, at 01:12 a.m., Lars Heuer <[email protected]> wrote:

>> Starting with the simple case - if no external references exist -
>> if you were to load the map into a topic maps environment, you'd
>> have a few different choices for defining an IRI for resolution of internal identifiers:
> 
>>        a) the filesystem path location of the source map, e.g. file:///some/path/to/map.xtm,
>>        b) the mechanism that clients would connect to the server
>> implementation to access the information within the map.xtm instance,
>>        c) some kind of serialization-specific explicit base location specifier
> 
> In a previous msg you said we should escape from the one topic map per
> document/resource assumption and now you present only one topic map
> per resource options.

Yes, I did, and I still believe this. I was trying to keep the example simple, and when you're acting on a TMRM map, it must be temporally bounded in order for the model to remain consistent. Again, deferred closure is my general approach until the last possible time t.

[...]

> That's all well and good. But you define a resolution mode which may
> not work for the TMQL implementation X. Your implementation isn't a
> standard. Is your resolution the same as the local identifier
> resolution in Perl::TM? Maybe it is, but I am talking about a standard
> with standardized test cases etc.

I'm fully aware my implementation isn't standard, but lessons and ideas seem reasonable to consider as input to a standard so the widest possible implementations of it are still possible.

I've actually no idea if my item resolution is the same as Perl::TM as I've never used it. However, my goal is to provide an implementation that will eventually pass standardised test cases.

> [...]
>> IRI (even if it follows the JDBC IRI model for some custom API
>> access path) that should be used as the base IRI for local identifiers.
> 
> We cannot assume that. What happens if the map is a stream without any
> information about the source IRI of the stream? At some point we have
> to provide an address. AFAIK all recent standards (even those which
> work on an abstract model) like XPath/XSLT/XQuery or SPARQL require
> some address to resolve identifiers against. And all standards define
> a standardized resolution mechanism on purpose.

I wasn't thinking that we'd assume this. I would've thought that we could specify the expected behaviour in terms of abstract access mechanisms similarly to [1]. In your stream example, or when there wasn't any base directive, then processors could raise errors. In most cases, I believe that a standardised model of relative identifiers should be possible based on the explicit access mechanism.

[...]
> [...]
>> None of the above.  The address of your environment map would be
>> based on the mechanics of providing the view of these maps to the
>> processor (in terms of the engine's accessing mechanisms).
> 
> Okay, but at some point you have to become concrete. That's the way
> how standards work.
> 
> Even if I like your view, this view does not work for ISO standards.
> I bet that your implementation of TMQL delivers different results than
> the TMLab's implementation or rho's implementation.

Well, as I said, mine's parked for the moment, so it won't deliver any results! ;)

However, the intention is to provide consistent results with the spec for a given input so that it won't surprise people working with data they know, and it will pass standardised tests.

> Again, I have to skip the rest of your msg, now due to sleep
> constraints. :) But in general I don't think that our positions are
> far away, I'm just wearing my ISO standard hat.

Fair enough. I guess I'm gonna lose this one. Maybe that's why I've never participated in ISO standards before. My fear is that people will agree a solution which, with just a bit more effort, would be equally valid yet allow more flexible implementations.

Thanks for the discussions,

ast

[1] http://www.w3.org/TR/html401/struct/links.html#resolving-relative-uris