[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]