Subject: Re: Data encoding paper comments
From: Rick Reed TSE (rickreed#tseng.co.uk)
Date: Tue Jun 29 2004 - 19:00:25 GMT
Dear Harald,
Thanks for the comments - just in time before I update the paper.
Harald Böhme at boehme#informatik.hu-berlin.de wrote on 29/06/04 16:04:
> There was the point for teh easy integration of user defined encodings.
This was also raised in the ITU experts meeting.
> Change the set of predefined encodeing types from literals of a datatype
> to be self datatypes.
> How to do:
> - define a predefined base date type for all encodings
> - derive a predefined data type for each of the predefined encodings
> - the use is now abel to define own encoding, by derive own data types
> from the predefined base data type.
I see some advantage in this approach but also some problems.
For example, what does it mean to define a variable of one of these data
types?
While I guess we could make such a scheme work, my intuition is would be
more complex than the current proposal.
> There was an other issue with keep encoded "Messages" and forwarding.
>
> If the interfaces/signal-lists from two different endpoints for a agent
> differs, he is not abel to forward the request, becaus of diferent
> encoding of the messages.
Actually it would almost work - but not as I intended! The reason is that
the (draft) Z.104 is defined in terms of the models given in the paper. So
on an input the message would get stored as as a string, and at this point
no conversion is required so this could be implemented efficiently. On the
output the message is first decoded according to the encoding rule given in
the output. If this is the path the message was received from it gets
decoded as the choice of the implicit choice type of the input corresponding
the input signal. So far it would work provided the path given is the input
path rather than the output path!
This is then output and then re-encoded. It is at this point it would fail
unless the signals are to be conveyed on the same path they were received
on. The VIA would be used to direct the output (as well as determining the
path for the implicit decoding). If this is not the same path is the input
path it cannot be specified.
The problem is that:
VIA <path>
is used for two purposes:
1. to indicate the decoding of the stored expression;
2. to indicate the path to be taken.
I propose to resolve this as follows:
The syntax should be:
<encoded output> ::=
ENCODE <decode expression body> <communication constraints>
where
<decode expression> ::=
DECODE <expression body>
<decode expression body> ::=
<expression> [ <encoding path> ]
It is a requirement that for an <encoded output> there shall be exactly one
<via path> in its <communication constraints> and this <via path> shall
specify a gate or channel that has an encoding rule that corresponds to the
sort of the <expression> of the <encoding rule>.
If a VIA is given and <encoding path> is omitted then the implied path for
the encoding path is the path given for the VIA.
If no VIA is given, there shall be just one path
This would work fine for the case where ENCODE is used to create the value
which is stored in a variable used for the <expression> in the <decode
expression body>.
> The nameing for "textual encoding" should be chnage to some, what
> reflect more ist is ASCII, but not human readable.
Useful comment - I'll give the naming some more thought.
> There was an other point aboute calling encode/decode in an agent, but I
> don't rember exactly what.
Maybe related to the concept of user defined encoding rules??
-- Rick Reed - rickreed#tseng.co.uk Tel:+44 15394 88462 Mob.:+44 7970 50 96 50
This archive was generated by hypermail 2a23 : Mon May 05 2008 - 20:30:55 GMT