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
