[sc34wg3] CTM draft dtd. 2007-09-09 - Proposal for IRIs

Lars Heuer heuer at semagia.com
Sat Oct 20 09:22:05 EDT 2007

Hi Lars,

[Option to embed IRIS in angle brackets removed from TMQL]
>> IMO it is the wrong decision. If the committee would have decided that
>> IRIs must always be enclosed in angle brackets, I could understand it
>> (while I proposed to allow both syntaxes), but the removal is wrong
>> (reasons are listed in the proposal).

> What proposal?

This one:

In CTM (and TMQL) we have several situations where the character
followed an IRI can be interpreted as part of the IRI. The current
solution is to force at least one whitespace character which is
possible and valid work-around (I like to keep, BTW).

But practically, it would be nice to allow the angle brackets for CTM
fragments in e-mails (mentioned in the e-mail above) and for
situations where the following character can be interpreted as part of
the IRI (scope notation, associations, paramaters for templates and
TMQL functions).

Especially for templates and functions, the "whitespace after IRI"
rule looks weird:

     func(http://www.example.org , 12, 29)

Users are conditioned to add a whitespace *after* the comma
but not before a comma (see natural language).

If we allow the angle brackets, these things wouldn't look so weird
and we'd follow RFC 3986 and we'd adopt a widely used notation for

The user has to type the <> only if she wants, and smart editors could
aid the user and complement the '>' bracket if the user types '<'.

> Actually, they were removed because we didn't like them.

Sniff. ;)

> As far as I'm concerned SPARQL had little to do with it. But,
> anyway, how *does* SPARQL handle IRIs?

Sorry, I meant the syntax not the handling, actually. But SPARQL uses
the <> notation as several other syntaxes do.

> Note that things enclosed in <> do not embed very well in XML.

Right, my proposal was to allow both notations.

Best regards,

More information about the sc34wg3 mailing list