[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
<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
--------------090601030900020603000502
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<pre>From <a class="moz-txt-link-freetext" href="http://www.w3.org/TR/xmlschema-2/#union-datatypes";>http://www.w3.org/TR/xmlschema-2/#union-datatypes</a>
<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></pre>
<br>
<br>
Rich Thompson wrote:
<blockquote
cite="midOF64C78098.04DFF130-ON85257050.0045CC36-85257050.00478A58@us.ibm.com"
type="cite"><br>
<font face="sans-serif" size="2">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:</font>
<br>
<br>
<font face="sans-serif" size="2">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;</font>
<br>
<font face="sans-serif" size="2"><complexType
name="ExtensionDescription">
<!-- or <complexType name="CustomUserProfileItemDescription">
--></font>
<br>
<font face="sans-serif" size="2"> <sequence></font>
<br>
<font face="sans-serif" size="2"> <element name="description"
type="LocalizedString"/></font>
<br>
<font face="sans-serif" size="2"> <element name="location"
type="xsd:string"/></font>
<br>
<font face="sans-serif" size="2"> </sequence></font>
<br>
<font face="sans-serif" size="2"> <attribute name="name"
type="xsd:string"/></font>
<br>
<font face="sans-serif" size="2"> <attribute name="type"
type="xsd:QName"/></font>
<br>
<font face="sans-serif" size="2"> <attribute name="maxOccurs"
type="xsd:string"/> <!-- does schema have a better type
for this (positive_int | "unbounded")? --></font>
<br>
<font face="sans-serif" size="2"></complexType></font>
<br>
<br>
<font face="sans-serif" size="2">2. Where to put custom user profile
items ... I think I have heard a number of proposals:</font>
<br>
<font face="sans-serif" size="2"> 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.</font>
<br>
<font face="sans-serif" size="2"> 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.</font>
<br>
<font face="sans-serif" size="2"> 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).</font>
<br>
<br>
<font face="sans-serif" size="2">Does this reasonably capture where
we
are?</font>
<br>
<font face="sans-serif" size="2"><br>
Rich </font>
<br>
<br>
<br>
<table width="100%">
<tbody>
<tr valign="top">
<td width="40%"><font face="sans-serif" size="1"><b>"Andre
Kramer"
<a class="moz-txt-link-rfc2396E" href="mailto:andre.kramer@eu.citrix.com";><andre.kramer@eu.citrix.com></a></b> </font>
<p><font face="sans-serif" size="1">08/01/05 06:56 AM</font>
</p>
</td>
<td width="59%">
<table width="100%">
<tbody>
<tr>
<td>
<div align="right"><font face="sans-serif" size="1">To</font></div>
</td>
<td valign="top"><font face="sans-serif" size="1">"Subbu
Allamaraju"
<a class="moz-txt-link-rfc2396E" href="mailto:subbu@bea.com";><subbu@bea.com></a>, "wsrp" <a class="moz-txt-link-rfc2396E" href="mailto:wsrp@lists.oasis-open.org";><wsrp@lists.oasis-open.org></a></font>
</td>
</tr>
<tr>
<td>
<div align="right"><font face="sans-serif" size="1">cc</font></div>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td>
<div align="right"><font face="sans-serif" size="1">Subject</font></div>
</td>
<td valign="top"><font face="sans-serif" size="1">RE:
[wsrp] User Profile Items
- Samples</font></td>
</tr>
</tbody>
</table>
<br>
<table>
<tbody>
<tr valign="top">
<td>
<br>
</td>
<td><br>
</td>
</tr>
</tbody>
</table>
<br>
</td>
</tr>
</tbody>
</table>
<br>
<br>
<br>
<tt><font size="2">Another viewpoint is that the application (the
programmer)
knows the<br>
semantics of the extension. Therefore, all WSRP is required to do is to<br>
serialize and de-serialize profile items. This would mean that WSRP<br>
should just be prepared to transfer additions at any level, as Portlets<br>
will know both where to look and what the context is [no harm in meta<br>
data for this though]. <br>
<br>
My use case is a map location (GPS coordinates, says) that could be a<br>
profile item extension to both home or office or extend extensions.<br>
Forcing this to the top level requires extra work to (re)capture the<br>
relationships.<br>
<br>
Regards,<br>
Andre<br>
<br>
-----Original Message-----<br>
From: Subbu Allamaraju [<a class="moz-txt-link-freetext" href="mailto:subbu@bea.com";>mailto:subbu@bea.com</a>] <br>
Sent: 29 July 2005 22:38<br>
To: wsrp<br>
Subject: Re: [wsrp] User Profile Items - Samples<br>
<br>
<br>
Rich Thompson wrote:<br>
> <br>
> Relative to the three items you laid out as necessary statements,
<br>
> extensions already require use of the xsi:type attribute and I
think<br>
the <br>
> other two are definitional to what CustomUserProfileItem means
(though<br>
I <br>
> would not use the local name restriction ... I think the full
QName
<br>
> needs to match and this greatly reduces name collisions).<br>
> <br>
> I would note that carrying custom user profile items within the<br>
element <br>
> meant to carry extensions to the protocol is using the extensions<br>
field <br>
> for its intended purpose. I would also note that it would not
preclude<br>
<br>
> other types of things from also being carried as extensions as the<br>
QName <br>
> for each extensions element child provides the semantics for what
it <br>
> carries.<br>
<br>
The key point here is the need for a statement saying that "custom
<br>
profile items must be available as the _root_ element of an extensions
<br>
element under such and such user profile elememt".<br>
<br>
Without such a statement, there is less/no value in exposing names/types<br>
<br>
of custom user profile items within the protocol.<br>
<br>
Let's consider few cases.<br>
<br>
Producer A asks for custom profile items. Consumer A knows where the <br>
Producer A is going to look for extensions, and so can sends those <br>
profile items at runtime. Everything works as expected.<br>
<br>
Consumer B does not know how Producer A is implemented. It will send the<br>
<br>
same typed data in the wrong place. Producer B will either ignore those
<br>
or make some wrong guesses about those items.<br>
<br>
Without further specification, implementations will have to do a tree <br>
walk and guess work to recognize profile items. The fact that a given <br>
piece of data has the expected type does not imply that it has some <br>
known semantics/intent. Semantics/intent can only be defined by way of
<br>
specification.<br>
<br>
Regarding the point on the intended purpose of extensions, the <br>
specification should not depend on the extensibility model for interop.
<br>
I think that is where are disagreeing.<br>
<br>
Regards,<br>
<br>
Subbu<br>
<br>
<br>
<br>
> <br>
> Rich<br>
> <br>
> <br>
> *Nathan E Lipke <a class="moz-txt-link-rfc2396E" href="mailto:nlipke@bea.com";><nlipke@bea.com></a>*<br>
> <br>
> 07/29/05 01:09 PM<br>
> <br>
> <br>
> To<br>
> wsrp
<a class="moz-txt-link-rfc2396E" href="mailto:wsrp@lists.oasis-open.org";><wsrp@lists.oasis-open.org></a><br>
> cc<br>
> <br>
> Subject<br>
> Re:
[wsrp] User Profile Items - Samples<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> Rich,<br>
> <br>
> Thanks for your comments.<br>
> <br>
> I like the using element name as item name, xsi:type and
maxOccurs.<br>
> <br>
> However, I feel its a bit awkward to specify these in extensions.
This<br>
<br>
> would effectively be adding semantic rules to an <xs:any>.<br>
> <br>
> The spec would have state something like:<br>
> <br>
> * Custom User Profile Items MUST be placed in an element
which is<br>
a<br>
> child of the extensions field of the appropriate
user profile<br>
> section.<br>
> * The element's local name MUST be equal to the item's
name<br>
> * The element MUST have a xsi:type attribute,
the value of which<br>
is<br>
> the element's child's type.<br>
> <br>
> It seems awkward to tie such strong requirements to a
<xs:any>
field, <br>
> particularly extensions which are intended to be open for<br>
implementation <br>
> details.<br>
> <br>
> Furthermore, if the implementation also sent its own extensions
this
<br>
> could create a number of problems. The producer would have to<br>
determine <br>
> which extensions were meant to be customItems and which had
another
<br>
> purpose. Particularly troubling is the case where an true
extension's
<br>
> name match a custom item's name. In which case both could be sent,<br>
then <br>
> producer would then need to determine how to handle them.<br>
> <br>
> Thanks,<br>
> <br>
> Nate<br>
> <br>
> Thanks for producing these examples. In looking at them, I think a
<br>
> couple of things are turned around:<br>
> 1. the name attribute in the metadata should match the element
name
in<br>
<br>
> the runtime message as this carries the semantic information about<br>
what <br>
> the item is;<br>
> 2. the type information in the metadata is for the preparation of
<br>
> serializers/deserializers and should be carried at runtime using
the
<br>
> xsi:type attribute; and<br>
> 3. rather than the isArray style of RPC-encoded, I recommend a<br>
maxOccurs <br>
> attribute like what schema uses and perhaps even pushing this<br>
attribute <br>
> down into the schema for the type.<br>
> <br>
> Making these changes results in the following message formats for
the <br>
> extensions case ... the only difference for the customUserItems
case<br>
is <br>
> the name of the parent element.<br>
> <br>
> <br>
> <br>
> Other changes I would propose (but did not include here in order
to
<br>
> limit the scope of the next part of the discussion) would be<br>
broadening <br>
> the metadata type so that it was not explicit to<br>
customUserProfileItems <br>
> (perhaps ExtensionItemDescription), including a ResourceList for <br>
> multi-language versions of the description and possibly a
ModelTypes<br>
for <br>
> carrying schema information inline.<br>
> <br>
> Rich<br>
> <br>
>
---------------------------------------------------------------------<br>
To <br>
> unsubscribe from this mail list, you must leave the OASIS TC that
<br>
> generates this mail. You may a link to this group and all your TCs
in <br>
> OASIS at: <br>
>
<a class="moz-txt-link-freetext" href="https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php";>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php</a><br>
<br>
<br>
---------------------------------------------------------------------<br>
To unsubscribe from this mail list, you must leave the OASIS TC that<br>
generates this mail. You may a link to this group and all your TCs
in<br>
OASIS<br>
at:<br>
<a class="moz-txt-link-freetext" href="https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php";>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php</a>
<br>
<br>
---------------------------------------------------------------------<br>
To unsubscribe from this mail list, you must leave the OASIS TC that<br>
generates this mail. You may a link to this group and all your TCs
in OASIS<br>
at:<br>
<a class="moz-txt-link-freetext" href="https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php";>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php</a>
<br>
<br>
</font></tt>
<br>
---------------------------------------------------------------------
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:
<a class="moz-txt-link-freetext" href="https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php";>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php</a> </blockquote>
</body>
</html>
--------------090601030900020603000502--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]