RE: Proposed new requirement: Ability to produce textual output

 

 - 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            [email protected]
GSM: +47 926 82 437           http://www.ontopia.net


-----Original Message-----
From: [email protected] [mailto:[email protected]]
On Behalf Of Lars Marius Garshol
Sent: 24 June 2003 11:29
To: [email protected]


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

* Robert Barta
| 
| That's true, it would quite often be useful. I considered using this 
| for LaTeX output (for the TM->slides stuff), but then decided against
| it: TM engineering seems to be all about a decent 
| 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?
 
| Still, from an architectural point of view, nothing can stop a vendor 
| to create XML (which contains the formatted text) and XSLT-postprocess 
| this behind the scenes. If that is too expensive then why not hand 
| 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.
 
| Allowing arbitrary text to be generated WITHIN a TMQL query statement 
| will have ugly consequences on the syntax: To avoid ambiguity you 
| would have to introduce explicit terminators around the text. If these 
| should then appear in the text they have to be escaped, blablabla.
 
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.

-- 
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
[email protected]
http://www.isotopicmaps.org/mailman/listinfo/tmql-wg