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

[Chris Angus]

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

Yes

* - 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?

Why not specify an abstract model for output, with XML and templated raw
text as two specific physical output forms specified as part of TMQL.
Other physical output forms based on the abstract model MAY be specified
as separate extensions.  The SHALL requirement would be to produce
output in one or more of the conformant forms (i.e. conformant to the
abstract model).
______________________________________________________________________
=20
Chris Angus
Product Architect
Kalido Ltd
=20
Direct:  +44 (0)20 7934 4960
Home:    +44 (0)16 9774 1504
Fax:     +44 (0)20 7934 3377
http://www.kalido.com
=20

-----Original Message-----
From: Lars Marius Garshol [mailto:larsga@garshol.priv.no]=20
Sent: 24 June 2003 10:29
To: tmql-wg@isotopicmaps.org
Subject: Re: [tmql-wg] Proposed new requirement: Ability to produce
textual output


* 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;=20

* Robert Barta
|=20
| 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?
=20
| 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.
=20
| 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.
=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