You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Matthew Duftler <du...@us.ibm.com> on 2004/03/29 17:55:53 UTC
Re: [jsr110-eg-disc] Extensibility Attributes
I've committed the discussed changes; the history is down below.
I've also updated the tck to reflect these changes.
Thanks,
-Matt
Matthew Duftler
To: jsr110-eg-disc@yahoogroups.com
03/19/2004 05:08 cc:
PM From: Matthew Duftler/Watson/IBM@IBMUS
Subject: Re: [jsr110-eg-disc] Extensibility Attributes(Document link: Matthew Duftler)
To continue the earlier conversation, I am proposing the following
additions to javax.wsdl.extensions.ExtensionRegistry:
public void registerExtensionAttributeType(Class parentType, QName
attrName, int attrType)
public int queryExtensionAttributeType(Class parentType, QName attrName)
the following additions to javax.wsdl.AttributeExtensible:
public static final int NO_DECLARED_TYPE = -1;
public static final int STRING_TYPE = 0;
public static final int QNAME_TYPE = 1;
public static final int LIST_OF_STRINGS_TYPE = 2;
public static final int LIST_OF_QNAMES_TYPE = 3;
and the following changes to javax.wsdl.AttributeExtensible:
from:
public void setExtensionAttribute(QName name, QName value);
public QName getExtensionAttribute(QName name);
to:
public void setExtensionAttribute(QName name, Object value);
public Object getExtensionAttribute(QName name);
AttributeExtensible should also probably move from javax.wsdl to
javax.wsdl.extensions.
If someone wants the current behavior, these modifications would not
require any changes other than a cast from Object to QName when calling
getExtensionAttribute(QName). That is, if no registration calls are made
(which will probably be common), the behavior will be what it is today.
Today, it assumes QName, but if the prefix cannot be resolved, returns a
QName with the whole string in the local part, and no namespace.
Thanks,
-Matt
Matthew
Duftler/Watson/IB To: jsr110-eg-disc@yahoogroups.com
M@IBMUS cc:
Subject: Re: [jsr110-eg-disc] Extensibility Attributes
03/19/2004 02:46
PM
Please respond to
jsr110-eg-disc
Hi Sam,
>The case I am struggling with is where the extensibility attribute
>contains a list of QNames (yea, yea, I know there is no direct simple
Yup, this is a problem.
So the cases we have are (w.r.t. the type of the extensibility attribute):
1) string (e.g. abc:def="123")
2) qname (e.g. abc:def="ghi:jkl")
3) list of strings (e.g. abc:def="123 456 789"); this is basically the same
as #1
4) list of qnames (e.g. abc:def"="ghi:jkl ghi:mno ghi:pqr")
The problem is that we never know the type of an extensibility attribute
before reading or writing it.
I can think of two solutions that would allow us to handle all 4 cases
correctly:
1) Add some methods to the ExtensionRegistry to allow a client of JWSDL to
register the type (string, qname, list-of-strings, list-of-qnames) of a
particular extensibility attribute (when it exists as the child of a
specific element). We would also need to change the AttributeExtensible
interface to treat the type of the attribute's value as Object, so it can
be cast to the correct java type (string, qname, list). If no type is
pre-registered for an attribute, then its value can default to the current
behavior (that is, qname). I think it will be much simpler to use than it
may seem by this description. Almost every case will require no extra work;
the unusual cases, like the one you describe, will simply require one
registration call ahead of time.
or
2) Add a variety of methods to the AttributeExtensible interface to allow
every extensibility attribute to be retrieved as a particular type. This
would involve parsing the value every which way ahead of time, or else
namespace information will need to be maintained everywhere.
I think the first option is a much more elegant solution.
What does everybody think?
This really needs to be decided quickly, since we'd like to put out a
maintenance release.
Thanks,
-Matt
Samuel Meder
<meder@mcs.anl.go To:
jsr110-eg-disc@yahoogroups.com
v> cc:
Subject: Re:
[jsr110-eg-disc] Extensibility Attributes
03/11/2004 04:25
PM
Please respond to
jsr110-eg-disc
On Thu, 2004-03-11 at 14:48, Matthew Duftler wrote:
>
>
> Hi Sam,
>
> I guess the problem is if you return a string, and the type of the
> attribute is actually a qname, you will need some sort of namespace
context
> within which to resolve the prefix.
>
> If you return a qname, and the type of the attribute is a string, you can
> either explicitly set the default namespace for that element to "", or
> ignore the namespace altogether.
The case I am struggling with is where the extensibility attribute
contains a list of QNames (yea, yea, I know there is no direct simple
type for it, but say it is of type NMTOKENS with the right
restrictions). If you actually enforced the QName typing you'd have to
throw an error when encountering a list of QNames (considering the
[NCName:]NCName requirement), so forcing the type to QName seems bad to
me.
As it turns out, I can currently work around this issue since the IBM
implementation does not enforce the NCName issue, but that does not
necessarily seem portable.
At the very least the JSR should include language that the
implementation is not to enforce the QName type when parsing
extensibility attributes.
All in all I would be happier with a alternative call that would give me
a string instead of a QName (even if it is in addition to the current
call rather than replaces it). Also where namespace resolution is
concerned I am happy to just assume that all namespace declarations were
made on the definitions element and that I can thus use the calls
provided on that element to resolve any prefixes I find. Maybe not quite
correct, but hey...
/Sam
> Thanks,
> -Matt
>
>
>
> Samuel Meder
> <meder@mcs.anl.go To:
jsr110-eg-disc@yahoogroups.com
> v> cc:
> Subject: [jsr110-eg-disc]
Extensibility Attributes
> 03/08/2004 11:33
> AM
> Please respond to
> jsr110-eg-disc
>
>
>
>
>
>
>
> What lead to the decision to force the type for extensibility attributes
> to QName? As far as I can tell the WSDL 1.1 schema leaves the type of
> the extensibility attribute open, so why not return a String?
>
> /Sam
>
> --
> Sam Meder <me...@mcs.anl.gov>
> The Globus Alliance - University of Chicago
> 630-252-1752
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
--
Sam Meder <me...@mcs.anl.gov>
The Globus Alliance - University of Chicago
630-252-1752
Yahoo! Groups Links
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/jsr110-eg-disc/
<*> To unsubscribe from this group, send an email to:
jsr110-eg-disc-unsubscribe@yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/