OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsrp] User Profile Items - Samples



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:
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]