wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] User Profile Items - Samples
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp <wsrp@lists.oasis-open.org>
- Date: Mon, 1 Aug 2005 09:29:19 -0400
Moving the maxOccurs down into the schema
had also been one of my comments. I left it for now to let others weigh
in. I think the original motivation was supporting multiple occurrences
of a simple type ... We already have a reusable StringArray type, but not
IntArray, etc.
Rich
Subbu Allamaraju <subbu@bea.com>
08/01/05 09:19 AM
|
To
| wsrp <wsrp@lists.oasis-open.org>
|
cc
|
|
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
---------------------------------------------------------------------
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]