[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".
[...]
> 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. ;-)

:) There is no other draft, of course, but the community (that
includes me to some extend), seems to be unhappy with TMQL. I think
TMQL is consistent (with a few bugs) but I like to change some things
and I think TMQL would gain a higher acceptance in the community if
some things change and some things are dropped. I am not talking about
a new language here, I just think that TMQL needs some further work
and I hope the community (and committee) follows the "fixing issues"
path.

[...]
> 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.

I agree that standards are not meant to be consumed by "normal"
people, but I think examples help even "abnormal" people who want to
implement the standard. The standard itself must be consistent, of
course.

[...]
>> 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?".
[....]
> Hmmm, sure, opinions differ on the practice. Do you think this regex matches
> what is found in RFC 3987?

Well, the escaped syntax (<IRI-here>) is matched by the RFC, but the
new CTM syntax for unescaped (non-rootless) IRIs does not cover the
whole RFC but that's intentional: We just want to cover the use case
where the IRI exists of a schema name (like http, or https, or ftp,
or...) and the "://" follows that schema name. That's the common use
case. For all other schemas, like "mailto" the user could use the
'<IRI-here>' syntax.


[...]
>> 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.

As said, I was never a big supporter of that mental model. Even if I
think that "Eating your own dogfood" is preferable, you have to take
the "everything looks like a nail" assumption into account. Regarding
prefixes and QNames I'd go the traditional way. The standard should
not forbid to tread the prefix / IRI tuple as topic, but IMO it is
wrong to mandate that.

> PS: Thanks for the latest CTM draft!

To be written........ :(

Best regards,
Lars

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