[tmql-wg] Proposed new requirement: Ability to produce textual output

[Graham Moore]

=20

 - 1. do we all agree that the ability to produce output fom TMQL is a
   good thing?

 * yes.

 - 2. should we say that this ability MAY be specified in a separate
   part (that is, not in part 1 of TMQL)?

 * When you say 'not in part 1' do you mean the first version of tmql or =
not
in the main section describing the language?

 - 3. should we make the ability to produce non-XML output a SHALL
   requirement, a MAY requirement, or just leave it out?

 * hmm - once we have the mechanism to output XML format why should it =
be
any harder for it to be non-XML? I think just leave it out. (1) above =
covers
any kind of output.

----------------------------------------------------------------
Graham Moore, Ontopian            moore@ontopia.net
GSM: +47 926 82 437           http://www.ontopia.net


-----Original Message-----
From: tmql-wg-admin@isotopicmaps.org =
[mailto:tmql-wg-admin@isotopicmaps.org]
On Behalf Of Lars Marius Garshol
Sent: 24 June 2003 11:29
To: tmql-wg@isotopicmaps.org


* Lars Marius Garshol
|
| Well, that assumes the users will be happy to use both TMQL and XSLT=20
| to get what they want, rather than use TMQL to produce it directly.
| Producing non-XML output is actually quite common;

* Robert Barta
|=20
| That's true, it would quite often be useful. I considered using this=20
| for LaTeX output (for the TM->slides stuff), but then decided against
| it: TM engineering seems to be all about a decent=20
| knowledge/information management. Working around XML then seems to be =
a
bit inconsistent.

What do you mean? XML isn't the be-all and end-all of information =
management
(that's why we have TMs :), so personally I don't see a problem with =
this.
If XSLT can transform to text rather than just XML, why would it be =
wrong
for topic maps to do the same?
=20
| Still, from an architectural point of view, nothing can stop a vendor=20
| to create XML (which contains the formatted text) and XSLT-postprocess =

| this behind the scenes. If that is too expensive then why not hand=20
| back raw data and use a homegrown templating mechanism.

Sure, it's always possible to get around whatever we don't put into =
TMQL.
The question is just whether it's better to standardize this capability =
or
whether it's better to leave it for extensions.
=20
| Allowing arbitrary text to be generated WITHIN a TMQL query statement=20
| will have ugly consequences on the syntax: To avoid ambiguity you=20
| would have to introduce explicit terminators around the text. If these =

| should then appear in the text they have to be escaped, blablabla.
=20
We agree on that. I'm not sure whether that has to be bad, but clearly =
it
could be.

Some questions for the people on this list, and the more of you who tell =
us
what you think, the better:

 - do we all agree that the ability to produce output from TMQL is a
   good thing?

 - should we say that this ability MAY be specified in a separate
   part (that is, not in part 1 of TMQL)?

 - should we make the ability to produce non-XML output a SHALL
   requirement, a MAY requirement, or just leave it out?

Come on, people, let us hear what you think.

--=20
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >

_______________________________________________
tmql-wg mailing list
tmql-wg@isotopicmaps.org
http://www.isotopicmaps.org/mailman/listinfo/tmql-wg