Re: [wsrp] User Profile Items - Samples

[Subbu Allamaraju <subbu@bea.com>]

I think you have captured the summary very well.

Just one comment. Strictly speaking, the maxOccurs attribute should 
belong to the type of the profile item.

Subbu

Rich Thompson wrote:
> 
> In order to make sure we are making progress, I would like to pause and 
> summarize my understanding of our current state. I think there have been 
> two issues raised relative to custom user profile items:
> 
> 1. Need to explicitly declare type information. Whether this type ends 
> up being called CustomUserProfileItemDescription or ExtensionDescription 
> likely depends on our answer to #2, but does anyone have additional 
> thoughts/comments about this type; namely;
> <complexType name="ExtensionDescription"> <!-- or <complexType 
> name="CustomUserProfileItemDescription"> -->
>   <sequence>
>       <element name="description" type="LocalizedString"/>
>       <element name="location" type="xsd:string"/>
>   </sequence>
>   <attribute name="name" type="xsd:string"/>
>   <attribute name="type" type="xsd:QName"/>
>   <attribute name="maxOccurs" type="xsd:string"/> <!-- does schema have 
> a better type for this (positive_int | "unbounded")? -->
> </complexType>
> 
> 2. Where to put custom user profile items ... I think I have heard a 
> number of proposals:
>   a. Since these are extensions to the protocol, place them in the 
> extensions element of the structure they are extending ... understanding 
> the semantics and locating the extension element is no different than 
> for any other extension.
>   b. Since these are common extensions and could get confused with other 
> extensions, either place them in a new open content element or within a 
> predefined extension element which always holds just custom user profile 
> items.
>   c. Refine option b (or possibly even option a) to move these elements 
> to the UserProfile level so that there is a well known place to look for 
> them (Note that this may require a common attribute to tell what 
> structure is really being extended).
> 
> Does this reasonably capture where we are?
> 
> Rich
> 
> 
> *"Andre Kramer" <andre.kramer@eu.citrix.com>*
> 
> 08/01/05 06:56 AM
> 
> 	
> To
> 	"Subbu Allamaraju" <subbu@bea.com>, "wsrp" <wsrp@lists.oasis-open.org>
> cc
> 	
> Subject
> 	RE: [wsrp] User Profile Items - Samples
> 
> 
> 	
> 
> 
> 
> 
> 
> 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
> 
> ---------------------------------------------------------------------
> 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