RE: [wsrp] User Profile Items - Draft Proposal

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

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