[infod-wg] Issue 2.2 - update

[Djaoui, A (Abdeslem)]

>>- suggestion to isolate the expression name from the proposed urn for subscription expressions (StevenD) 
I have now included a name=attribute to allow us to name expressions uniquely.
>>- suggestion to support expression names that would be shared across subscriptions (Dieter)
expressions can be given a unique name, stored in the registry an reused.



Here is the updated proposal.


Abdeslem
/////////////

quick description of what an EPR is
====================================
EPR stands for EndPoint Reference. It's a way to refer to web service instance(s). It is defined in WS-Addressing and its content is as follows

<wsa:EndpointReference>
    <wsa:Address>xs:anyURI</wsa:Address>
    <wsa:ReferenceParameters>xs:any*</wsa:ReferenceParameters> ?
    <wsa:Metadata>xs:any*</wsa:Metadata>?
</wsa:EndpointReference>

The Address element is a URI that can be the physical address of a service or it could be just a name (URN) that can subsequently be resolved to an address (more on this later). This is the only part of an EPR that is required.
Reference parameters (optional): can be used to help dispatch the message to the correct instance (these show up as SOAP headers).
Metadata (optional): This allows the inclusion of any additional metadata about the endpoint. 

So how can we use EPR for dealing with 
1)a subscription on behalve of a single consumer, 
2) a list of consumers and 
3) and expression?

Note that the way we do it is specific to InfoD registry (and is not *standard*). Apart from when using a standard EPR to refer to an endpoint (case 1 bepow), these EPR constructs are internal to InfoD.

1) is the simplest as it involves simply passing a standard EPR to the registry. Nothing new here.
2)When dealing with a list of consumers I propose the use of a URN (urn:infod:subscription-list:dieter:ballroom-dance-news:1) 
for the address 
and include the list of EPRs in the metadata section. The URN is then used as an identifier of the subscription. When the EPR is passed to the registry,
the registry maintains the list of consumers assosiated with that particular subscription.
We will need to define at least one operation to the registry (resolveEPR), that takes an EPR and returns an updated  one. 

3) we could define an infod specific URN (urn:infod:subscription-expression:dieter:ballroom-dance-news:1). Note the use
of subscription-expression instead of subscription-list. This will also be passed in the metadata section of the EPR, We would need to define a new infod specific element for this

<infod:Expression Dialect="xs:anyURI" name="xs:anyURI">
{any}
</infod:Expression>

By dialect I mean SQL or XPATH or XQuery, ... and name is a unique name for the expression. This can be stored in the registry and reused.
When this EPR is passed to the registry, the registry evalutes the expression and stores the list of consumers.