Re: Proposed new record syntax for use within GRS-1 - float

Alan --

I can't see any harm adding floating point as an additional choice to
ElementData. Presumably, clients who need to receive floating point
data (very few I assume) would implement this change, and others would
be unaffected. (Unless servers send floating point unrequested, why
would they do that?)

The question is does anyone want this?  If you've got a solution that
works and nobody else needs to do it, I don't see a reason to amend
grs, but if others want this I'll be glad to put up a proposal.

--Ray


----- Original Message ----- 
From: "Alan Kent" <ajk@mds.rmit.edu.au>
To: "ZIG" <www-zig@w3.org>
Sent: Sunday, February 22, 2004 10:59 PM
Subject: Proposed new record syntax for use within GRS-1 - float



GRS-1 supports a number of primitive data types, but misses floating
point values. Rather than change the spec, we have used our own
EXTERNAL
for dropping floating point values in. Here is the ASN.1 we use

    TT-20-Float {z39-50-recordSyntax 1000 62 1 4} DEFINITIONS ::=
    BEGIN
    IMPORTS z39-50-recordSyntax FROM Z39-50-Oids;
    -- Record syntax for holding floating point values in GRS-1
records.
    -- This is used in the 'ext' member of the 'ElementData' type.
    FloatValue ::= REAL
    END

Is it worth registering this somewhere? Or standardising it (in
particular
the record syntax OID)? Does anyone else think putting floating point
values in GRS-1 records is useful? Not sure if its a record-syntax
or something else, but it was used within a record so record-syntax
seemed appropriate. I could not imagine using it directly in a present
response however. Its really only for use within GRS-1.

The alternative is adding to the GRS-1 CHOICE for ElementData, but
this would not be backwards compatible and 'ext' is available for
dropping in EXTERNALs so why not use it. (If people felt adding
a CHOICe was a better approach I would not be against it.)

Alan

Received on Monday, 23 February 2004 10:08:00 UTC