wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] User Profile Items - Samples
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp <wsrp@lists.oasis-open.org>
- Date: Fri, 29 Jul 2005 16:45:36 -0400
Relative to the three items you laid
out as necessary statements, extensions already require use of the xsi:type
attribute and I think the other two are definitional to what CustomUserProfileItem
means (though I would not use the local name restriction ... I think the
full QName needs to match and this greatly reduces name collisions).
I would note that carrying custom user
profile items within the element meant to carry extensions to the protocol
is using the extensions field for its intended purpose. I would also note
that it would not preclude other types of things from also being carried
as extensions as the QName for each extensions element child provides the
semantics for what it carries.
Rich
Nathan E Lipke <nlipke@bea.com>
07/29/05 01:09 PM
|
To
| wsrp <wsrp@lists.oasis-open.org>
|
cc
|
|
Subject
| Re: [wsrp] User Profile Items
- Samples |
|
Rich,
Thanks for your comments.
I like the using element name as item name, xsi:type and maxOccurs.
However, I feel its a bit awkward to specify these in extensions. This
would effectively be adding semantic rules to an <xs:any>.
The spec would have state something like:
- Custom User Profile Items MUST be placed
in an element which is a child of the extensions field of the appropriate
user profile section.
- The element's local name MUST be equal
to the item's name
- The element MUST have a xsi:type
attribute, the value of which is the element's child's type.
It
seems awkward to tie such strong requirements to a <xs:any> field,
particularly extensions which are intended to be open for implementation
details.
Furthermore, if the implementation also sent its own extensions this could
create a number of problems. The producer would have to determine which
extensions were meant to be customItems and which had another purpose.
Particularly troubling is the case where an true extension's name match
a custom item's name. In which case both could be sent, then producer would
then need to determine how to handle them.
Thanks,
Nate
Thanks for producing these examples.
In looking at them, I think a couple of things are turned around:
1. the name attribute in the metadata should match the element name in
the runtime message as this carries the semantic information about what
the item is;
2. the type information in the metadata is for the preparation of serializers/deserializers
and should be carried at runtime using the xsi:type attribute; and
3. rather than the isArray style of RPC-encoded, I recommend a maxOccurs
attribute like what schema uses and perhaps even pushing this attribute
down into the schema for the type.
Making these changes results in the following message formats for the extensions
case ... the only difference for the customUserItems case is the name of
the parent element.
Other changes I would propose (but did not include here in order to limit
the scope of the next part of the discussion) would be broadening the metadata
type so that it was not explicit to customUserProfileItems (perhaps ExtensionItemDescription),
including a ResourceList for multi-language versions of the description
and possibly a ModelTypes for carrying schema information inline.
Rich
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]