FW: [sc34wg3] CTM: Working draft for Montreal

[Steve Pepper]

This *extremely* valuable message was posted by a "lurker", Andreas Sewe,
who only has read-only access to the list. (In general, only members of WG3
can post.) Since I am not able to approve his posting immediately (because I
don't have my password with me here in Montreal ^^) and our f2f is tomorrow,
I am forwarding it instead.

Thank you very much for these comments, Andreas, in particular those
relating to URIs. Some things clearly have to be tidied up in that area. (In
fact, after Harry Halpin's presentation here at Extreme today, I think we
probably shouldn't use QName at all, but rather invent something more
well-defined.)

I also like your idea of a CSS-inspired syntax. We'll discuss it tomorrow.

--
Steve Pepper, Convenor, SC34/WG3
 
 

-----Original Message-----
From: Andreas Sewe [mailto:sewe at rbg.informatik.tu-darmstadt.de] 
Sent: 10 August 2006 18:55
To: Discussion of ISO/IEC 13250 Topic Maps
Subject: Re: [sc34wg3] CTM: Working draft for Montreal

Steve Pepper wrote:
> A first working draft of ISO 13250-5 Topic Maps - Compact Syntax
> (CTM) will shortly be published in the SC34 document repository. In
> the meantime a copy has been posted at
> 
> http://www.ontopia.net/work/13250-6.pdf
> 
> Please review this draft and send your comments to this mailing list
> in advance of the Montreal meeting (August 11-13). CTM will be the
> main topic of discussion in Montreal, so please make your opinions
> known.

Well, I might be just a lurker on this list, but hopefully my comments
are useful to you anyway:

- Section 5.1.3, Datatypes, states that strings can be enclosed in both
double quotes and triple double quotes. It is unclear, however, what
benefit the latter option offers. The spec is silent on this. (I assume
they do what they do in Python.)

It is also, outside its EBNF appendix, silent on whether the following
is legal: (It is according to the EBNF.)

   """12-22"""^^xsd:gMonthDay

If triple double quotes are to be kept, although personally I see no
argument in favour, an example like the above would be useful in section
5.1.3.

- Furthermore section 5.1.3, Datatypes, makes an exception for http:
IRIs when it comes to enclosing them in angle brackets. Unfortunately
this is ambiguous: http:contentType can be both a QName and a valid
http: *IRI reference*.

It is not a valid *IRI*, however, since RFC 3987's definition of IRI
excludes relative references. But unfortunately the draft uses the term
"IRI" in conjunction with the xsd:anyURI datatype; this datatype does
allow relative references. This issue needs to be clarified.

- Also the spec text of explicit datatype assignments in section 5.1.3
seems buggy: "Any datatype can be expressed by representing the value as
a string and appending the datatype-qualifier (^^) and the IRI of the
datatype"

This is wrong; what is appended is not the datatype's IRI but a QName
placeholder of said IRI. In this light the possible ambiguity (depending
on how the IRI vs xsd:anyURI issue is resolved) above becomes even more
relevant, since one can express a datatype IRI both literally and
disguised as a QName, e.g.:

   "application/xml"^^http:contentType
   "application/xml"^^<http://www.w3.org/1999/xx/http#contentType>

Unfortunately the EBNF adopts a misleading terminology, speaking of
iri-references when referring to either IRIs or QNames. The terminology
really ought to be brought in line with the RFCs 3986 and 3987 on URIs
and IRIs, respectively.

- It might be worth of allowing the "empty assertion", since experience
(e.g. with CSS) has shown that using, e.g., a semicolon as separator
instead of as terminator can be confusing to authors; it would be all to
easy to forget changing the period to a semicolon when appending
assertions, for example.

If the empty assertion were allowed, however, the following would be
possible:

subject-1
   assertion-1;
   assertion-2;

subject-2
   assertion-3;

- Also, it strikes me as odd that there is an abbreviated syntax for
associating multiple assertions with a single subject, but asserting a
fact about multiple subjects at once is not made easy.

Again, CSS had to deal with a similar issue; it has selectors and rules
instead of subjects and assertions, but its principles apply to CTM as well.

So what about a CSS-inspired syntax like the following:

subject-1, subject-2 {
   assertion-1;
   assertion-2;
}

The above would then be merely a abbreviation for the following:

subject-1 assertion-1.
subject-1 assertion-2.
subject-2 assertion-1.
subject-2 assertion-2.

- On the issue of comments I do not have a strong preference for
allowing either single-line comments only or both single- and multi-line
comments. I would appreciate it, however, if in the former case only #
would be used whereas the latter case should use // and /* */, respectively.

This is because a lot of people familiar with C99/C++ will likely be
confused when (having /* */ multi-line comments) single-line comments
are introduced by # and not by //. Similarly, if only single-line
comments were allowed, // would suggest that there are /* */ multi-line
comments, too, even if there are not. In that case # ought to be chosen
to mark comments.

- As with every new format there is always the issue of registering a
media type. Are there any plans to do so?

- And will there be an application/topicmap+xml media type? IMHO, there
really ought to be one, since a lot of dispatching on the web is based
on a representation's Content-Type.

Regards,

Andreas Sewe