[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]