[sc34wg3] TMQL Chapter 4, Sections 1 + 2

[Lars Heuer]

Hi Patrick,

I am not sure if it makes sense to discuss the current draft in detail
since there seems to be attempts to change TMQL "Here, There and
Everywhere".

Anyway, maybe I can clarify a few points.

> First, let me say up front that I would lose all the examples, both here
> and elsewhere.

I think keeping the examples would be good. Even if a standard is not
meant as tutorial, the examples help the reader to get an access to
the abstract topic.

[...]
> 4.2 becomes:
>
> *****
> Atoms are values drawn from the data types listed in Table 1.
> *****
>
> Only partially defined by CTM. References W3C for date and date-time
> (note error in TMQL draft, which reports dateTime).

IMO this is a minor task. Aside from "undef" and the iri notation TMQL
is pretty aligned to CTM. IIRC the TMQL editors want to loose the
boolean datatype anyway.
Regarding "dateTime": Yes, I've chosen the notation date-time since it
fits better in the naming scheme for productions.
I think that the TMQL standard either will refer to the CTM standard
for its datatypes or will use the same productions as CTM. Not a big
issue at all (aside from the "iri" production which has to be fixed
since it looks like a string).

> Well, except for the escape character doesn't appear in the regex. Need
> to fix that or better yet reference a regex with it already present.

I think the regexes will be fixed once the TMQL editors use the
correct (not Perl-alike) stylesheet.


[...]
> Not to mention that it would be easier to say: IRIs as defined by RFC
> 3987 and then to move on. Noting that the productions there bear little
> resemblance to /([^<>'{}|^`] - [#x00-#x20]])*/ as found in TMQL.

In CTM we've gone the other way around: We provided a regex to define
"That's an IRI" and the committee said "Well, we have the nice RFCs,
we could simply put a reference to them into CTM, please do that". We
made that. In one of the next meetings the committee said "Well, you
reference the RFC here, wouldn't it be cool if we could have a regex
just to have a common understanding what that production means?".
Yeah, cool idea. :) Personally I think having regexes is better than
just referring to another document.

> Odd that identifier should be limited to ASCII text under the current
> proposal.

Should be aligned to CTM as well.

> "Otherwise one such subject indicator - together with the identifier in
> the QName - is used to construct an absolute IRI according to the rules
> in [RFC3986] (5.2, Relative Resolution)."
>
> The final statement seems to presume that the subject indicator can
> meaningfully be used with the QName to construct an identifier. I don't
> know of any fixed relationship between QNames and subject indicators
> that are found in a topic. Is this meant to enforce such a relationship?
> Particularly since a topic can have more than one subject indicator.

I think it is meant as: If you declare a prefix A for URI B that
prefix is handled like an item identifier and is putted into the
environment map and the URI B becomes automatically a subject
identifier of that prefix.
If you try to resolve a QName, the interpreter looks for the "prefix"
part of the QName and looks for the subject identifier of the prefix.
If a topic has more than just one subject identifier, TMQL treats all
these ontologies as one ontology, I guess.
I was never a big supporter of handing prefixes as topics, though. I
think it would be better to keep the prefix -> URI mapping outside the
Topic Maps model.

Best regards,
Lars

-- 
Semagia
<http://www.semagia.com/>