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

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:33:10 UTC