Next in thread →
Next in month →
Re: [wsrp] Schema types for ScopedPropertyDescription
Looks good. On a quick glance at this portion of the primer, I noticed that message 26 needs the same change. Rich Subbu Allamaraju <> 01/14/06 09:50 PM To wsrp <> cc Subject Re: [wsrp] Schema types for ScopedPropertyDescription 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 <>* > > 12/15/05 08:54 AM > > > To > wsrp <> > 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 <>* > > > > 12/14/05 02:34 PM > > > > > > To > > wsrp <> > > 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 --------------------------------------------------------------------- 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 →