Re: Instance and Definition of Voucher

[Ko Fujimura <fujimura@isl.ntt.co.jp>]

Raghuram Rajah wrote:

> A few thoughts about the Voucher definition.
> 
> 4. Component Structure - Defining the components associated with the voucher
> itself (like ValidPeriod), seem to constraint the potential of the voucher.
> Wouldn't it be better to define a overall framework that can support an
> ability to define meta-data and behaviour. We can standardize some meta-data
> like ValidPeriod, but the issuer should be able to define more.
> 
> Also, in one of Ko's earlier presentation (when discussing requirements), I
> saw a division of the voucher into two parts - Definition and the actual
> voucher. I felt the approach was admirable, for it provided a mechanism to
> define the shape of the voucher and the data as two seperate entities.Making
> a distinction between the core voucher and the meta-description information,
> helps a lot when the voucher has to be stored on a limited device like the
> smart card.
> 
> We had built a "voucher" (we called it coupon) system for the smart card.
> Let me go over that design philosophy, which are in line with one of Ko's
> earlier presentation. Thus, I would think the voucher is defined by two
> entities,
> 
> - Voucher Definition. Defines the shape and behaviour of the voucher.
> - Voucher Instance. The core data of the voucher based on the defintion.

In the XML voucher document (Page 2), there is a description:

     Note: This document uses a "voucher" as an "instance of voucher"
     whose meaning is defined by Voucher Component. In other words,
     multiple vouchers can be issued and managed by the VTS using the
     same Voucher Component.

It might not be clear enough. But, I use "Voucher Component" as the meaning 
of "Voucher Definition". So, the current document already assumes the 
separation of the Definition and Instance. But, values of properties 
are also specified in the Definition if the value is fixed across the same 
type of the voucher as you pointed out.

The Voucher Component is used to make consensus between trading partners 
what/how the voucher are traded. In this sense, I think that the contents 
of voucher should be exchanged between the trading partners before actual 
"delivery of voucher instance" or "rewrite of the ownership". In this sense,
it should be specific enough so that trading partners can agree the item to 
be traded. I use Voucher *Component* since it might be used in offer exchange 
or other trading transactions.

The "instance of voucher", on the other hand, can be implemented as the 
identifier (or hash) of the Voucher Component if the Voucher Component is 
specific enough. This approach is key to achieving implementation flexibility 
and efficiency. 

By the way, the data structure of the "instance of voucher" is completely left 
to the VTS implementation. It may includes some VTS-specific parameters needed 
for preventing duplicate redemption, etc.

> 
> The Voucher Definition defines the genre of coupon,
> 
> eg. x% off any purchase greater than $y between m1/d1/y1 and m2/d2/y2 - Defn
> A
>     $x off purchase at YYY Store - Defn B
> 
> The Voucher Instance on the other hand is the actual coupon that specifies
> the values of variables,
> 
> eg. Coupon Defn A; x=5; y=25; m1/d1/y1 = 11/2/2000; m2/d2/y2 = 12/25/2000
>     Coupon Defn B; x=25; YYY = Sears
> 

Both of these Definition and Instance are considered as Voucher Component in my 
definition. But, I think it is possible to introduce such a layered definition 
within Voucher Component. It introduces, however, more implementation complexity. 
So, I didn't include this facility in the first version of the draft specification.

Thanks.

Ko