[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] User Profile Items - Samples
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]