[sc34wg3] TMQL Chapter 4, Sections 1 + 2

[Patrick Durusau]

Lars,

Lars Heuer wrote:
> 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.
>
>   
Well, I don't know of any other draft to discuss other than the one 
before WG 3. At least that would focus the discussion on what is known, 
even if parts of it are unwanted. ;-)
>> 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.
>
>   
True but as I said, more extensive and useful examples can be placed in 
an annotated version. And that could include snippets of actual code, 
something that is unlikely to appear otherwise.

I don't disagree with your premise about examples being helpful, my only 
concern is that we make standards short and direct. Being easy to read 
is the job of secondary literature.
> [...]
>   
>> 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).
>
>   
OK.
>> 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.
>
>   
Hmmm, sure, opinions differ on the practice. Do you think this regex 
matches what is found in RFC 3987?
>> 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.
>   
OK, that makes sense.

There could be a problem with using prefixes as item identifiers if 
there is a clash between them. For example, in ODF (unfortunately) we 
define our own "svg" prefix with a URI. So, if you had the "svg" 
compatible namespace from ODF and the "svg" namespace from the W3C, then 
you would have two item identifiers with different URIs. Note that we 
redefine some things, mostly subsetting but not always in the "svg" 
compatible namespace so I am not sure it would be accurate to say it is 
"one ontology." I strongly suspect the SVG crowd at the W3C would say not.

Hope you are having a great day!

Patrick

PS: Thanks for the latest CTM draft!

-- 
Patrick Durusau
patrick at durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)