[sc34wg3] TMQL: Restrict tm-content and xml-content to return clause

Robert Barta rho at devc.at
Fri Feb 27 02:48:25 EST 2009


On Wed, Dec 03, 2008 at 04:59:38PM +0100, Lars Heuer wrote:
> I like to suggest that TMQL should restrict the usage of XML to the
> return clause of a FLWR expression. I already suggested it one year
> ago but I am unsure about the state:
> <http://www.ontopia.net/tmwiki/topic.jsp?id=tmql-xml-everywhere>
> 
> Further, I suggest to restrict "tm-content" also to the return clause
> otherwise we have to accept something like
> 
>     for $p in """donald isa duck
>                  - "Donald"
>               """
>     return $p
> 
> Is this really necessary?

Hi Lars,

The answer to your question above depends on how one approaches the
design of languages in general.

When dealing with user interfaces, buerocracies, etc the attitude
towards the user is more "guiding" (governmental), in the sense that
"we know what is best for you, trust us". That may be justified or
not, but when developing languages for communication in this sector,
then "dark spots" emerge. I.e. things which per se do exist, but you
cannot express them because the language does not allow you it. As you
definitely know George Orwell's Newspeak[1] analyzes this nicely.

So your question "is this really necessary" I reinterpret as asking do
we want people to guide NOT to use this orthogonal feature.

I for myself cannot presume for me to know what all their applications
of the language will be. I think we should just try to offer an
orthogonal feature set. "Orthogonal", because it means that

  _every_ feature works the same in _every_ context used

This is a principle to fight language complexity.

And even if we would follow your suggestion to remove TM content at
_THAT_ particular position, it would not forbid the use:

  for $p in { return """donald isa duck""" }
  return $p

If we allow nested expressions (which we do), then we would have _a
lot_ to do to forbid that use.

\rho

[1] http://en.wikipedia.org/wiki/Newspeak


More information about the sc34wg3 mailing list