Re: [wsrp] User Profile Items - Samples

[Rich Thompson <richt2@us.ibm.com>]

Thanks for tracking this down ... now
to resolve the question of whether to reference it or push the issue down
into the type of the custom user profile item. My preference is to push
it down and have it resolved at the schema level.

Rich

Nathan E Lipke <nlipke@bea.com>

08/03/05 11:21 AM

To	Rich Thompson/Watson/IBM@IBMUS
cc	wsrp <wsrp@lists.oasis-open.org>
Subject	Re: [wsrp] User Profile Items - Samples

From http://www.w3.org/TR/xmlschema-2/#union-datatypes

    <attribute name="maxOccurs"use="optional"
default="1">
      <simpleType>
        <union>
          <simpleType>
            <restriction base='nonNegativeInteger'/>
          </simpleType>
          <simpleType>
            <restriction base='string'>
              <enumeration value='unbounded'/>
            </restriction>
          </simpleType>
        </union>
      </simpleType>
    </attribute>


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