Re: [wsrp] User Profile Items - Draft Proposal

[Subbu Allamaraju <subbu@bea.com>]

Just to make sure that this thread is not lost, Rich and Mike - could 
you include this topic on the list of open issues?

Regards,
Subbu

Rich Thompson wrote:

>
> I would agree that the connection between the semantics, carried by 
> the element name, and the syntax, defined by its type, can be entirely 
> carried within schema. I think the base question is whether to carry 
> that connection using schema syntax or WSRP metadata syntax. Both can 
> associate a QName with a type definition, but I think the effort 
> required to construct/parse is different.
>
> Consider the case of 5 non-spec items of type NamedString:
> - Using schema syntax would have the WSRP metadata simply refer to the 
> schema (either in-line or by a URI reference) and the schema would 
> then contain 5 element definitions which connect the QName to the type 
> definition (much as the extra xsd file now has a definition for 
> "extra:doctype").
> - Using WSRP metadata syntax would require adding a type field in 
> appropriate places (e.g. ItemDescription) and should allow for 
> carrying schema definitions of such types to the partner.
>
> Personally neither of these connect the semantic and syntactic 
> definitions more strongly than the other.
>
> Rich
>
>
> *"Andre Kramer" <andre.kramer@eu.citrix.com>*
>
> 06/01/05 09:09 AM
>
> 	
> To
> 	Rich Thompson/Watson/IBM@IBMUS, "wsrp" <wsrp@lists.oasis-open.org>
> cc
> 	
> Subject
> 	RE: [wsrp] User Profile Items - Draft Proposal
>
>
>
> 	
>
>
>
>
>
> What I would avoid is a disassociation between fully qualified element 
> name and the type as in the following idiom:
>
> <somenamespace:somecontainerelement 
> type=”thisIsTheTypeTheElementNameDoesNotReallyMatter”>value</ 
> somenamespace:somecontainerelement>
>
> Hence, I avoided all use of a type attribute in favor to making an 
> item description describe the namespace. How about:
>
> ItemDescription
> [R] itemName string // item name (1.0) or unqualified name of XML 
> element if namespace attribute is carried
> [O] Attribute itemNamespace // new for 2.0
> [O] LocalizedString description // 1.0
> [O] Extension extensions[] // a bit circular here!
>
> Matching itemNamespace against SchemaLocation.namespace to discover 
> the schema for the item.
>
> Regards,
> Andre
>
> ------------------------------------------------------------------------
>
> *From:* Rich Thompson [mailto:richt2@us.ibm.com] *
> Sent:* 01 June 2005 12:55*
> To:* wsrp*
> Subject:* RE: [wsrp] User Profile Items - Draft Proposal
>
>
> Thinking out loud is definitely not a bad thing!
>
> I think there is value in having a centralized place that all non-spec 
> defined types can be carried. This should support both in-line and 
> referenced schemas. One still has the issue of connecting named items 
> to type information (in worst case this should be doable at runtime), 
> but at least half of the problem is dealt with in an overarching manner.
>
> On connecting named items to types, wouldn't adding an optional type 
> field to ItemDescription be simpler than most other approaches (and 
> backwards compatible to boot)?
>
> Rich
>
> *"Andre Kramer" <andre.kramer@eu.citrix.com>*
>
> 06/01/05 07:30 AM
>
> 	
> To
> 	Rich Thompson/Watson/IBM@IBMUS, "wsrp" <wsrp@lists.oasis-open.org>
> cc
> 	
> Subject
> 	RE: [wsrp] User Profile Items - Draft Proposal
>
>
>
> 	
>
>
>
>
>
>
> Thinking out loud:
>
> Then we should consider defining a new element SchemaDescription that 
> can carry a namespace name for an extensions as well as a ModelTypes 
> (an any) and / or a schemaLocation URI? This could be added at the 
> ServiceDescription and the PortletDescription to provide type 
> information on user profiles and any other extension? And 
> customUserProfileItemDescriptions would just enumerate the namespaces 
> used for profile related extensions.
>
> SchemaDescription
> [R] URI Namespace // match against custom*Items and extensions
> [O] ModelTypes ModelTypes
> [O] URI schemaLocation
>
> ModelDescription seems too property related. We may want to consider 
> such schema description support for coordination too.
>
> Regards,
> Andre
>
>
>
> ------------------------------------------------------------------------
>
> *
> From:* Rich Thompson [mailto:richt2@us.ibm.com] *
> Sent:* 01 June 2005 12:00*
> To:* wsrp*
> Subject:* RE: [wsrp] User Profile Items - Draft Proposal
>
>
> I would agree that it is misleading to claim UserProfile is not 
> extensible in v1 as extension points exist at every level in the 
> hierarchy, including the base. What was accepted as an issue at the 
> F2F is that there is no means to exchange type metadata about custom 
> user profile items. I could see ModelDescription as a good candidate 
> for how to exchange this information, but do not see a need to change 
> the way such items are carried at runtime (i.e. as extension elements).
>
> Rich
>
> *"Andre Kramer" <andre.kramer@eu.citrix.com>*
>
> 06/01/05 04:09 AM
>
> 	
>
>
> To
> 	"Subbu Allamaraju" <subbu@bea.com>, "wsrp" <wsrp@lists.oasis-open.org>
> cc
> 	
> Subject
> 	RE: [wsrp] User Profile Items - Draft Proposal
>
>
>
>
> 	
>
>
>
>
>
>
> It's a bit miss leading to claim UserProfile elements can't be extended
> in 1.0. While I'm not opposed to using properties as a extension
> mechanism, I think the intent was to allow each of the UserProfile
> sub-elements to be extensible? E.g. EmployerInfo could carry standard
> codes for type-of-business in an extension element using some existing
> XML schema. Therefore, would it not be better to leave custom values to
> XML as an extension, at the appropriate level, relying on namespacing,
> rather than forcing a property model to be in use at the profile level?
>
> Regards,
> Andre
>
> -----Original Message-----
> From: Subbu Allamaraju [mailto:subbu@bea.com]
> Sent: 31 May 2005 20:46
> To: wsrp
> Subject: [wsrp] User Profile Items - Draft Proposal
>
> One of the action items at the last F2F was for Richard and me to
> propose a fix to the user profile related inconsistencies in the V1
> spec.
>
> I'm attaching a note on this for your review. Since Richard is out sick,
>
> I would appreciate if someone from IBM checks to see if it meets his
> concerns and use cases.
>
> Regards,
>
> Subbu
>
> ---------------------------------------------------------------------
> 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
>