Next in thread → Next in month →

RE: [wsrp] User Profile Items - Draft Proposal

From
Rich Thompson <>
Date
2005-06-01T15:25:49+00:00
ID
Thread
RE: [wsrp] User Profile Items - Draft Proposal
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"
<> 

06/01/05 09:09 AM

To

Rich Thompson/Watson/IBM@IBMUS,
"wsrp" <>

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

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"
<> 

06/01/05 07:30 AM

To

Rich Thompson/Watson/IBM@IBMUS,
"wsrp" <>

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

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"
<> 

06/01/05 04:09 AM

 

To

"Subbu Allamaraju"
<>, "wsrp" <>

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

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
Next in thread → Next in month →