Re: ACTION-58 Look into issues surrounding the use of the 'any' type in the IDL

Hi,

My action was related to investigate the any issue, although I have 
mixed it with the context key representation issue. It's my fault. So 
first of all if we decide to use the any type then my previous e-mail 
applies and explains all the issues we would need to take into account.

With respect to the context key issue I understand your point. It sounds 
good to me thinking about the context key as a file handle. However, I 
would not use integer bacause doing that you may end end up having 
scalability problems, perhaps it could be better to represent the 
context key as a string.

Best Regards

Rhys Lewis escribió:
> Hi Jose,
>
> Just wondering if we are discussing the right thing here. Maybe I missed
> something.
>
> It seems to me that the API needs to be able to pass REFERENCES to context
> keys to callers and to receive them back. So I might call a function to
> identify a device, passing in a set of HTTP headers. What I get back is an
> opaque reference to the context key. I've called these 'handles' on recent
> calls. I think of this as like a 'file handle' returned when opening a
> file. File handles uniquely identify an instance of an open file for a
> program, but they don't contain any information. A program makes further
> API calls to do other things with that file handle (reading the file,
> deleting it, retrieving its properties ...).
>
> The 'handle' doesn't encode anything about the context key itself. It's
> just a reference, valid for no longer than the 'session' that a caller has
> with the repository. The context key itself is something completely
> internal to the repository.
>
> The only way to use a handle for a context key is to make another DDR API
> call. We've talked about passing in a context key as part of the input
> information in calls that refine the context. We've also talked about it
> being used in retrieving properties. In each case all we actually need to
> pass around is a reference to the context key, in other words the handle
> not the key itself.
>
> The context key is clearly a complex object that contains lots of
> information. However, its actual structure is a matter for the
> implementation of the repository. Callers should have no means to peer
> inside the key, other than by making API calls to the DDR.
>
> If all that sounds correct, then the 'handle' for the context key merely
> has to identify it within a session that a caller has with the DDR. So,
> can't it just be an integer? Isn't all we need for the API something like
>
> typedef int DDRContextKeyHandle;
>
> Then a repository implementation simply has to maintain an internal
> mapping between the handles and the contexts it currently knows about.
>
> This kind of approach would make the WSDL trivial, for example.
>
> Best wishes
> Rhys
>
> -----Original Message-----
> From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On
> Behalf Of José Manuel Cantera Fonseca
> Sent: 31 July 2007 18:20
> To: public-ddwg@w3.org
> Subject: ACTION-58 Look into issues surrounding the use of the 'any' type
> in the IDL
>
>
> Hi all,
>
> I have been investigating into this issue and I'm reporting back to the
> WG. Also I propose possible solutions. First of all I have checked the
> official OMG IDL-WSDL mapping [1]. According to this mapping an OMG-IDL is
> mapped to an xsd:anyType. However, in [2] there are some concerns about
> the usage of anyType in WSDL and WebServices. The good news is that we
> don't need to strictly follow the OMG IDL-WSDL mappings. So
>
> Taking into account these two facts, I'm proposing the following approach:
>
> Let's create a new DDR-API type called DDRAny. This type will be defined
> as:
>
> typedef  any DDRAny;
>
> In the IDL-API spec everytime that we cannot commit to an specific type we
> will use DDRAny.
> In our normative WSDL binding we will map DDRAny to a xsd:string, avoiding
> the xsd:anyType / xsd:any. In the binding rules section we will create a
> rule that will say:
>
> If the language has a generic type, such as Object in Java or void* in
> C++, it should be mapped to it. Otherwise it should be mapped to a string.
>
> Another issue, is, do we really need to deal with anys? The answer is,
> yes, at least to model the context key.
>
> That's all for now
>
> Best Regards
>
> [1] http://www.omg.org/docs/formal/03-11-02.pdf
> [2] http://www.ibm.com/developerworks/xml/library/ws-tip-xsdcaution.html
>
>
>
>
>

Received on Wednesday, 1 August 2007 07:42:46 UTC