Re: [wsrp] User Profile Items - Samples

[Subbu Allamaraju <subbu@bea.com>]

Since the sendor application and receiving application may have been 
written by different programmers, they will have to rely on out-of-band 
means to understand the semantics. That's why I brought up the question 
of semantics.

Regards,
Subbu

Andre Kramer wrote:
> Another viewpoint is that the application (the programmer) knows the
> semantics of the extension. Therefore, all WSRP is required to do is to
> serialize and de-serialize profile items. This would mean that WSRP
> should just be prepared to transfer additions at any level, as Portlets
> will know both where to look and what the context is [no harm in meta
> data for this though].
> 
> My use case is a map location (GPS coordinates, says) that could be a
> profile item extension to both home or office or extend extensions.
> Forcing this to the top level requires extra work to (re)capture the
> relationships.
> 
> Regards,
> Andre
> 
> -----Original Message-----
> From: Subbu Allamaraju [mailto:subbu@bea.com]
> Sent: 29 July 2005 22:38
> To: wsrp
> 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
> 
> 
> ---------------------------------------------------------------------
> 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
>