W3C home > Mailing lists > Public > public-qt-comments@w3.org > December 2003

Re: [XQuery] SAG-XQ-005 Serializing Arbitrary Sequences

From: Per Bothner <per@bothner.com>
Date: Wed, 03 Dec 2003 00:04:51 -0800
Message-ID: <3FCD9923.4030909@bothner.com>
To: "Kay, Michael" <Michael.Kay@softwareag.com>
Cc: public-qt-comments@w3.org

Kay, Michael wrote:

>  > I think there is a need for "human-readable" serialization,
>  > which does not necessarily have to be reversible.
> 
> I agree that products will want to produce such output, but does it have 
> to be standardized? If it's only for humans to read, and not for 
> software to read, why do we need to specify its format?

Because someone might want to (say) generate a report or a file
as a text (non-html) file, and it is useful to have a standard for this.

E.g. given some numbers, I might want to produce a "report" like:

   The max is 99 and the min is 5.

A user expect to be able to write:

   "The max is ",max($vals)," and the min is ",min($vals),"."

or:

   concat("The max is ",max($vals)," and the min is ",min($vals),".")

depending on what the standard specifies wrt to whitespace.  But it is
useful for the standard to specify a specific result so I know what
output to expect for a given program.

> And if it's for humans to read, wouldn't one want to produce something 
> richer than a string of ASCII characters?

True most of the time.  But sometimes one wants to be able to generate
simple non-HTML output.  I think this is a useful feature, and I think
people will expect portable results.

Perhaps the "text output model" sufficies for these applications - but
unfortunately there appears to be no standard way to set serialization
parameters in an XQuery program, like you can for XSLT.  Also, it seems
less intuitive to have to write:

   <result>The max is {max($vals)} and the min is {min($vals)}.</result>

only to want the <result></result> to disappear.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/
Received on Wednesday, 3 December 2003 03:04:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:56:51 UTC