RE: [ws-dd] RE: Issue 127 - DPWS - Change schema for Relationshipmetadata element

[Dan Driscoll <Dan.Driscoll@microsoft.com>]

Agreed--at the Host level, you can't omit a Hosted service (the service ceases to exist as a Hosted service at that point).  At the Hosted level, I'm not sure there's any benefit to omitting it.

It makes more sense to me to make it mandatory in both cases.
--D

-----Original Message-----
From: Antoine Mensch [mailto:antoine.mensch@odonata.fr]
Sent: Monday, January 05, 2009 2:04 PM
To: ws-dd@lists.oasis-open.org
Subject: Re: [ws-dd] RE: Issue 127 - DPWS - Change schema for Relationship metadata element

Dan,

I did not realize that the Relationship could be useful in case of no
Hosted Services. If it is the case (and you seem to have scenarios for
that), then we can keep it as it was, but we still need to change the
default behavior when Hosted is missing: the current version of the spec
says that the implied value when Hosted is missing is the endpoint that
serves the metadata. This will not help in your scenario, and it does
not work anyway, as there is no way to infer some of the missing
subelements, as explained in the original mail.
For the second point, I agree that we could remove the Host/ServiceId
element altogether, if nobody is interested in the backward compatibility.
I'll take care of the schema changes.

Cheers

Antoine

Dan Driscoll a écrit :
>
> I think Hosted still needs to be (0, many) because some devices will
> exist which have no hosted services, but still want to publish a
> relationship section (perhaps because they are required to use an
> extensibility point exposed in Host?) This is a common pattern in
> devices that use DPWS for discovery and metadata, but use other
> protocols (often with fixed port numbers) for actual control.
>
> Host/ServiceId should either be mandatory or removed, but keeping it
> optional doesn't do very much for us. If we can't come up with a good
> reason to keep it (I can't think of any) then we should consider
> removing it entirely.
>
> Lastly, we'll need to update the schema and ensure that it's
> determininstic. Otherwise this looks good.
>
> Thanks!
>
> --D
>
> *From:* Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com]
> *Sent:* Tuesday, December 16, 2008 8:13 AM
> *To:* ws-dd@lists.oasis-open.org
> *Subject:* [ws-dd] Issue 127 - DPWS - Change schema for Relationship
> metadata element
>
> This issue is assigned the number 127. For further discussions on this
> issue, please refer to this issue number or use this thread.
>
> *From:* Antoine Mensch [mailto:antoine.mensch@odonata.fr]
> *Sent:* Tuesday, December 16, 2008 1:29 AM
> *To:* Ram Jeyaraman
> *Cc:* Antoine Mensch
> *Subject:* NEW Issue - DPWS - Change schema for Relationship metadata
> element
>
> Document: DPWS CD1
> Lines: 481-495
> *
> Description
> *Changes made to solve issues 038 and 039 highlighted the following
> issues with the current schema for the Relationship element and its
> sub-elements:
> - The wsa:EndpointReference of the wsdp:Host element should be
> mono-valued: because this EPR must contain the device stable
> identifier, it is by definition unique.
> - The wsdp:ServiceId of the wsdp:Host element should be optional: this
> element contains the same ID as the one used in the EPR above. It is
> therefore redundant. The rationale for keeping it optional and not
> suppressing it altogether is to preserve backward compatibility with
> the structures used in DPWS 1.0 (although it is not complete backward
> compatibility, as the namespace has changed).
> - The wsdp:Hosted element should be mandatory (occurrences 1-n instead
> of 0-n): this element contains two mandatory sub-elements,
> wsa:EndpointReference and wsdp:ServiceId. While the value of the first
> one can be inferred from the endpoint that is serving the
> Get(Metadata) request, the value of the second cannot. It is theefore
> not possible to infer the complete wsdp:Hosted content in its absence,
> unlike what is suggested in the current version of the spec.*
>
> Proposed resolution (new in **red, old in** **blue)
> *
> The normative outline should be updated as follows:
>
> <wsdp:Relationship Type="xs:anyURI" ... >
>  (<wsdp:Host>
>     <wsa:EndpointReference>endpoint-reference</wsa:EndpointReference>+
>     <wsdp:Types>list of xs:QName</wsdp:Types>?
>     <wsdp:ServiceId>xs:anyURI</wsdp:ServiceId>?
>     ...
>   </wsdp:Host>)?
>  (<wsdp:Hosted>
>     <wsa:EndpointReference>endpoint-reference</wsa:EndpointReference>+
>     <wsdp:Types>list of xs:QName</wsdp:Types>?
>     <wsdp:ServiceId>xs:anyURI</wsdp:ServiceId>
>     ...
>   </wsdp:Hosted>)*+
>   ...
> </wsdp:Relationship>
>
>
> The descriptive text should be updated accordingly.
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.176 / Virus Database: 270.10.2/1872 - Release Date: 02/01/2009 13:10
>
>

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php