Re: [wsrp] Schema types for ScopedPropertyDescription

[Subbu Allamaraju <subbu@bea.com>]

I'm working on updating message 29 in the primer, and I have a follow up 
question.

The current message is invalid since there is no element named "int" in 
the schema.

A valid message would be

<getPortletPropertiesResponse>
   <properties name=" stockSymbolList">
     <stringValue>AMZN</stringValue>
   </properties>
   <properties name="refreshInterval">
     <ns1:refreshInterval xmlns:ns1="somens">180</ns1:refreshInterval>
   </properties>
</getPortletPropertiesResponse>

Given that there needs to be an extra child element to the properties 
element to carry the refreshInterval, would the current recommendation 
help implementors?

That question aside, I would like to correct the primer with the above 
message, and also add the following text below the message

"In this message, the refreshInterval element of type "xs:int" and is 
defined in an external namespace."

Any objections to making this change?

Subbu


Rich Thompson wrote:
> 
> I agree that such language would be more explicit ... we should carry 
> the equivalent to all relevant places (e.g. including 
> EventDesscription). Any objections?
> 
> Rich
> 
> 
> *Subbu Allamaraju <subbu@bea.com>*
> 
> 12/15/05 08:54 AM
> 
> 	
> To
> 	wsrp <wsrp@lists.oasis-open.org>
> cc
> 	
> Subject
> 	Re: [wsrp] Schema types for ScopedPropertyDescription
> 
> 
> 	
> 
> 
> 
> 
> 
> The current language of the spec does not spell out this usage. I
> propose the following change to reflect this (under both
> PropertyDescription and ScopedPropertyDescription).
> 
> name: Name of the property being described. This is the name of the XML
> element, whose type is described by the type of the property below.
> 
> This will then make
> 
>     <ns1:expiryDate>2006-09-10T12:00:00-05:00</ns1:expiryDate>
> 
> valid.
> 
> Subbu
> 
> Rich Thompson wrote:
>  >
>  > I think there are a couple of issues here. The name becomes the name of
>  > the xml element when the event flows on the wire. The type describes the
>  > type of this element. For your example, this results in an xml structure
>  > of the form:
>  >
>  > <ns1:expiryDate>2006-09-10T12:00:00-05:00</ns1:expiryDate>
>  >
>  > (for those not familiar with the dateTime format, this represents 12:00
>  > EST on Sept. 10, 2006)
>  >
>  > Rich
>  >
>  >
>  > *Subbu Allamaraju <subbu@bea.com>*
>  >
>  > 12/14/05 02:34 PM
>  >
>  >                  
>  > To
>  >                  wsrp <wsrp@lists.oasis-open.org>
>  > cc
>  >                  
>  > Subject
>  >                  [wsrp] Schema types for ScopedPropertyDescription
>  >
>  >
>  >                  
>  >
>  >
>  >
>  >
>  >
>  > On page 26 of draft 12, there is some language around usage of the name
>  > and type elements. I have some comments on the current language.
>  >
>  > 1. name: The conformance statement reads that the name "MUST have a
>  > non-zero length. But this statement is redundant since "" is not a valid
>  > QName.
>  >
>  > 2. type: There is a statement reading
>  >
>  > "We would encourage these to be either from the set of schema defined
>  > types or be explicitly ...".
>  >
>  > This means that the following would be a valid description of a scoped
>  > property.
>  >
>  > <urn:transientPropertyDescriptions>
>  >   <urn:name>ns1:expiryDate</urn:name>
>  >   <urn:type>xs:dateTime</urn:type>
>  > </urn:transientPropertyDescriptions>
>  >
>  > To carry such a scoped property, the sender will have to construct some
>  > xml like
>  >
>  > <urn:transientProperty name="ns1:expiryDate">
>  >    <xs:dateTime>2005-12-31</xs:dateTime>
>  > </urn:transientProperty>
>  >
>  > But this is invalid since there is no such element named dateTime.
>  >
>  > So, unless I'm mistaken, we can't make a recommendation to use schema
>  > types. The only exception is the "xs:string" type, since strings can be
>  > carried via the stringValue element.
>  >
>  > BTW, the primer has such an invalid XML, and needs to be fixed.
>  >
>  > Any comments? Am I missing something?
>  >
>  > 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
>  >
>  >
>  > --------------------------------------------------------------------- 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