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



Rich Thompson wrote:
> 
> 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.

The key point here is the need for a statement saying that "custom 
profile items must be available as the _root_ element of an extensions 
element under such and such user profile elememt".

Without such a statement, there is less/no value in exposing names/types 
of custom user profile items within the protocol.

Let's consider few cases.

Producer A asks for custom profile items. Consumer A knows where the 
Producer A is going to look for extensions, and so can sends those 
profile items at runtime. Everything works as expected.

Consumer B does not know how Producer A is implemented. It will send the 
same typed data in the wrong place. Producer B will either ignore those 
or make some wrong guesses about those items.

Without further specification, implementations will have to do a tree 
walk and guess work to recognize profile items. The fact that a given 
piece of data has the expected type does not imply that it has some 
known semantics/intent. Semantics/intent can only be defined by way of 
specification.

Regarding the point on the intended purpose of extensions, the 
specification should not depend on the extensibility model for interop. 
I think that is where are disagreeing.

Regards,

Subbu



> 
> 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
> 
> --------------------------------------------------------------------- To 
> unsubscribe from this mail list, you must leave the OASIS TC that 
> generates this mail. You may a link to this group and all your TCs in 
> OASIS at: 
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



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