[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [ws-dd] Issue 133: Metadataversion in metadata
------------------------ Ursprüngliche Nachricht ------------------------- Betreff: RE: [ws-dd] Issue 133: Metadataversion in metadata Von: "Dan Driscoll" <Dan.Driscoll@microsoft.com> Datum: Di, 13.01.2009, 16:52 An: "ingo.lueck@udo.edu" <ingo.lueck@udo.edu> -------------------------------------------------------------------------- Hi Ingo- Thanks for putting together this proposal. Please forward it to the WS-DD TC mailing list--during the last conference call (or the call before that?) the objections to this issue came from other TC members. Thanks very much --D -----Original Message----- From: Ingo Lueck [mailto:ingo.lueck@udo.edu] Sent: Tuesday, January 13, 2009 7:46 AM To: Dan Driscoll Subject: RE: [ws-dd] Issue 133: Metadataversion in metadata Hi Dan, my proposal is to add the metadata version as an element to ThisDevice. I think this is quit a small change to provide a reliable way of getting the correct metadata version: SCHEMA: <xs:element name="ThisDevice" type="tns:ThisDeviceType" /> <xs:complexType name="ThisDeviceType" > <xs:sequence> <xs:element name="FriendlyName" type="tns:LocalizedStringType" maxOccurs="unbounded" /> <xs:element name="FirmwareVersion" type="xs:string" minOccurs="0" /> <xs:element name="SerialNumber" type="xs:string" minOccurs="0" /> <xs:element ref="wsd:MetadataVersion" /> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax" /> </xs:complexType> EXAMPLE: <wsdp:ThisDevice xmlns:wsdp="http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01" > <wsdp:FriendlyName xml:lang="en-GB" > ACME ColourBeam Printer </wsdp:FriendlyName> <wsdp:FriendlyName xml:lang="en-US" > ACME ColorBeam Printer </wsdp:FriendlyName> <wsd:MetadataVersion>75965</wsd:MetadataVersion> </wsdp:ThisDevice> Best regards, Ingo > Hi Ingo- > In both cases, the only consequence of having an out-of-date metadata > version is that the client may have to retrieve metadata one extra time if > an updated Hello is published with the existing metadata version. > > This seems like an optimization problem that will not be a problem in > usual operating environments. > > Do you have a concrete proposal to bring to the TC? If we do not have a > concrete proposal, we cannot make any changes to the specification. > > The concerns raised on the last call indicate to me that this will be > difficult to solve, and that it only helps optimize the message exchange > (i.e., it is only to support optimizing the case where a message is lost, > or to support other optimizations such as out-of-band address > configuration). > > Thanks > --D > > -----Original Message----- > From: Ingo Lueck [mailto:ingo.lueck@udo.edu] > Sent: Monday, January 12, 2009 11:01 AM > To: Dan Driscoll > Subject: Re: [ws-dd] Issue 133: Metadataversion in metadata > > Hi Dan, > > here are two patterns for this issue: > > Pattern one: > > * Device issues Hello with metadataversion=1; client receives Hello; > * Device issues Hello with metadataversion=2; Hello dropped due to network > congestion > * Client needs the Device now and retrieves metadata; > > Now the client has metadata of version 2 but assumes that it is version 1. > > > Pattern two: > > * Device is already running > * Client comes to the network and knows the Address of the Device already > (by configuration, persistence or any other way) > * Client retrieves metadata > > Now the client has metadata but does not know the associated version > number. It could get the version number by means of a Probe or Resolve > request but this generates much traffic and delay just to figure out the > version number. Moreover, even doing so the client can't be sure to know > the correct number in the end. Here is the extended pattern: > > * Device is already running (metadataversion=1) > * Client comes to the network and knows the Address of the Device already > (by configuration, persistence or any other way) > * Client retrieves metadata > * Device issues Hello with metadataversion=2; Hello dropped due to network > congestion > * Client sends a probe directly to the Device; client receives Probe Match > with metadataversion=2 > > Now the client has metadata of version 1 but assumes that it is version 2. > > > I think adding the metadata version number to the metadata is a small and > straightforward change that solves all these Problems. > > Best regards, > Ingo > > > >> Hi Ingo- >> I would like us to make progress on this issue before the conference >> call >> next Tuesday. I believe some other members of the TC raised concerns >> about this proposal in December. >> >> I was thinking about this issue-does this problem actually exist? I'm >> trying to follow the pattern where a client could associate the metadata >> with an old version. >> >> I believe the pattern goes like this: >> >> >> * Device issues Hello with metadataversion=1; client receives >> Hello; client retrieves metadata >> >> * Device issues Hello with metadataversion=2; Hello dropped due >> to >> network congestion >> >> * Device issues Hello with metadataversion=3; client receives >> Hello; client retrieves metadata >> >> At both points (metadataversion=1, metadataversion=3), the client simply >> retrieves the metadata and knows that it is the latest version. Even if >> the device does not revise its metadataversion after the dropped Hello, >> the client will always receive the metadataversion in the most recent >> WS-Discovery message. >> >> Can you describe the case where metadataversion inside metadata is >> required? >> >> Thanks! >> --D >> > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]