[sc34wg3] TMQL Chapter 4, Sections 1 + 2

[Patrick Durusau]

Greetings!

Apologies for being late. It was a long week.

Continuing to explore the recesses and crannies of the latest draft of 
TMQL (http://www.isotopicmaps.org/tmql/tmql.html).

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

I assume this is being authored in markup so production of a version 
with even *more* examples for an annotated version of the final text 
should be trivial. That would allow an annotated version to concentrate 
on being a tutorial like document and allow the standard to concentrate 
on being a standard.

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).

Might be easier to simply invoke the data types as defined by the W3C 
and list those in table 1.

Besides, number is simply wrong. There are lot of non-ASCII digits in 
the world. I really don't see why we need this limitation.

I don't know what to make up decimal patterns being preferred over 
shorter integer patterns? For what purposes? By who or what? Suggest 
lose that line without more explanation.

The rest of that paragraph is just repeitition so strike it as well.

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.

Lose the examples as I said before.

Oh, the IRI or QName to explicitly provide data type? Not available 
except on strings. I don't see how the reference to clause 8 helps 
anything?

The next paragraph starts:

"For references either absolute IRIs or QNames can be used:"

Should read:

"Item references can be either absolute IRIs or QNames."

Suggestion: Rather than dipping in and out of the formal syntax, why not 
simply make all the prose statements, uninterrupted by the formal syntax 
and then express the same material in a concluding section? Or subsection?

Actually my preference would be to simply define all the material once, 
in prose and then in a normative annex have the formal grammar that 
tracks the statements in the prose.

That serves the audience of readers who prefer prose as well as those 
who prefer to simply read formal productions.

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.

Same should be true for prefix.

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

Lose the language following [16] identifier.

IRIs can be defined both in prose and in productions but let's do it 
fully in both places, not half in and half out.

Same observation for QNames.

Lose the Note on prefixes.

In the paragraph that starts: "If the item reference is a QName, then 
the ...."

Suggest: "If an item reference is a QName, then the QName prefix 
(without the trailing colon ":") is a topic identifier for a topic of 
type tmql:ontology in the effective map. It is an error if no such topic 
exists."

OK, now what? We have declared an error condition. Does the processor 
just laugh? Out loud or silently?

Then,...

"If no subject indicator for that ontology topic exists, then an error 
will be flagged."

Gee, that sounds a lot worse than simply having an error. ;-)

It seems to assume that the tmql:ontology topic exists, so we are past 
the first error condition, but now we find that the topic exists but 
doesn't have a subject indicator? Now we get "flagged." Now what?

We can say the handling of errors is implementation defined but we 
really should say something.

Besides, all this is at odds with: "This International Standard does not 
define an API (application programming interface) to interact with query 
processors and also refrains from naming certain error conditions."

Unless you think these are "certain other error conditions."

And that paragraph concludes:

"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.

Hopefully this will be a better week.

Hope everyone is at the start of a great week!

Patrick

-- 
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)