Adding HelperContext as a parm for (URI, Name) methods

[Brian Murray <br...@gmail.com>]

Has there already been discussion about adding a HelperContext parm for
methods which take URI and name as input?

It seems necessary to me.  For example, if you've created a Type with
helperContext1.getXSDHelper().define() or
helperContext1.getTypeHelper().define(),
then DataGraph.createRootObject(URI, name) will be unaware of the Types
created in the helperContext1 scope.

Re: Adding HelperContext as a parm for (URI, Name) methods

[Frank Budinsky <fr...@ca.ibm.com>]

Brian,

There is already spec discussion about possibly deprecating the DataGraph 
interface entirely. Even if that doesn't happen, I think that the (URI, 
name) methods should be deprecated.

Frank.

"Brian Murray" <br...@gmail.com> wrote on 03/20/2007 10:28:29 
AM:

> Thanks Kelvin.
> 
> That is a workaround for the example I provided.  However, the absence 
of
> HelperContext as a parm does seem to render createRootObject(URI, Name) 
and
> DataGraph.getType(URI, name) of very limited use.
> 
> The DataGraph methods are different from the following:
> DataObject.createDataObject(propertyName, URI, name)
> DataObject.createDataObject(propertyIndex, URI, name)
> in that a user of these DO methods would subsequently use a TypeHelper 
or
> XMLHelper - which is where the HelperContext comes into play.  (i.e.  I
> would not think that HelperContext should be a parm to these functions.)
> 
> It may be that the answer is simply - Don't use the DataGraph (URI, 
name)
> methods.  However, this seems to me to be an excellent opportunity for 
user
> error.  Should I start a thread on the spec side for this topic?


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Adding HelperContext as a parm for (URI, Name) methods

[Brian Murray <br...@gmail.com>]

Thanks Kelvin.

That is a workaround for the example I provided.  However, the absence of
HelperContext as a parm does seem to render createRootObject(URI, Name) and
DataGraph.getType(URI, name) of very limited use.

The DataGraph methods are different from the following:
DataObject.createDataObject(propertyName, URI, name)
DataObject.createDataObject(propertyIndex, URI, name)
in that a user of these DO methods would subsequently use a TypeHelper or
XMLHelper - which is where the HelperContext comes into play.  (i.e.  I
would not think that HelperContext should be a parm to these functions.)

It may be that the answer is simply - Don't use the DataGraph (URI, name)
methods.  However, this seems to me to be an excellent opportunity for user
error.  Should I start a thread on the spec side for this topic?

Re: Adding HelperContext as a parm for (URI, Name) methods

[kelvin goodson <ke...@gmail.com>]

Brian,
  this would be an issue for the SDO spec, but I don't think it's
necessary,  since you can use

Type type =helperContext1.getTypeHelper().getType(uri, name);
and then use
dataGraph.createRootObject(type);

the root object will then provide the type scope context for subsequent
updates to the graph

Regards, Kelvin.

On 20/03/07, Brian Murray <br...@gmail.com> wrote:
>
> Has there already been discussion about adding a HelperContext parm for
> methods which take URI and name as input?
>
> It seems necessary to me.  For example, if you've created a Type with
> helperContext1.getXSDHelper().define() or
> helperContext1.getTypeHelper().define(),
> then DataGraph.createRootObject(URI, name) will be unaware of the Types
> created in the helperContext1 scope.
>