Re: WS-RA issue 9700 disposition

OK, nobody can say I didn't try... I accept the WG resolution. Thanks.

Cheers

Antoine

PS: regarding the implementation overhead, I agree that filtering 
unknown formats is no big deal. I am more worried about the fact that 
popular tools (that we want to be interoperable with) might be coded as 
to always request a particular type of content, and that we may just 
have to support it if we cannot indicate that we have an alternative one.

Doug Davis a écrit :
>
> Antoine wrote on 05/14/2010 03:37:33 AM:
> > > > I am still not convinced that the existing mechanisms will allow 
> us to
> > > > profile out the Content attribute in DPWS servers: I agree that 
> because
> > > > the attribute is optional and has a default value of ".../Any" it is
> > > > easy to profile out its use in DPWS clients, but it is not enough.
> > >
> > > You're correct that a service _will not_ be able to profile out the
> > > Content attribute.  The WG discussed this and it was felt that 
> allowing
> > > a service to not support the Content attribute would revert the spec
> > > back to its
> > > old state which wasn't optimal.
> > Maybe not for you, but it was perhaps optimal for device vendors who
> > have been implementing this spec for 5 years in 512 KB of Flash and 96
> > KB of RAM (and yes that's kilobytes, not megabytes, including OS,
> > middleware and applications). I am not against making the life of the
> > client easier, but it shouldn't be at the expense of making the life of
> > the server impossible.
>
> Its a balancing act. You may need to expand on this a bit for me because
> mex isn't requiring people to support any Content URI that they don't 
> want to,
> so from a server perspective it might require additional IF statements to
> ensure the client is only asking for what the server can support but that
> doesn't seem like asking too much.
>
> ...
> > > > Should it look at the WS-Policy assertion (thus making it kind of
> > > > mandatory, and also creating a bootstrap problem)?
> > >
> > > Ideally yes.  :-)  that's why its there.  If people choose not to 
> use the
> > > recommended advertising approach there isn't much we can do.
> > Policy assertions are not always easy to get and extract from their
> > enclosing document, especially in the case of WS-Mex policy assertions,
> > as you need to figure out how to get them out-of-band (bootstrap 
> problem).
>
> Getting WS* Metadata in general isn't the easiest, that's for sure.
> But (and this is just my opinion) I think now that MEX has the GetWSDL()
> operation it should at least make sure that everyone has the same single
> starting point for getting the stuff they're interested in.  So, doing
> a GetWSDL() should return a WSDL doc that contains the MEX assertion
> with the data you're looking for.  Yes there might be references in there
> instead of the data itself, but at least we know where those should be.
> As for bootstrapping, I'm hoping people get into the habit of placing
> the MEX assertion into EPRs they pass around.
>
> ...
> > > True, but there were a couple of concerns with this that the WG
> > > discussed:
> > > - this is, in essence, creating another advertising mechanism. 
>  Having
> > > both
> > > policy and this seemed redundant.
> > It can also be called a redirection/negociation mechanism, a bit like
> > the 3xx codes in HTTP, which some people find useful. Also, policy
> > applies to each dialect (class-level information), while the
> > mex:AlternateContent would apply to each individual instance
> > (resource-level information), so I don't think it would be that 
> redundant.
>
> re:3xx - sort of.  Although, that works at a different level (the 
> entire doc and not
> a sub-resource of the doc), and 3xx is telling you where to go to get the
> doc you asked for, not where to go to get something similar.  But I do
> understand your point and I'm sympathetic to it - the WG just couldn't
> get past the fear of the added complexity they saw.
>
> ...
> > > - while this seems like a nice benefit for those clients that will
> > > want to
> > > issue a secondary request, it creates a bit of noise for those 
> clients
> > > that
> > > do not want this information.  Akin to "why are you telling me you 
> have
> > > oranges when I asked for apples?"
> > Well to expand on the metaphor, if you go to your grocer's shop and ask
> > for apples, the guy is very likely to offer you oranges instead if he
> > doesn't have apples, and if you're really hungry, you're going to buy
> > them! ;)
>
> LOL probably true - but if I was hungry (which I am right now) I'd
> turn around and ask what else they had ("Any") w/o needing to be 
> prompted,
> or being the picky eater that I am, I'd probably ask about the
> smaller list of things that I'm willing to choke down.  :-)
>
> thanks,
> -Doug
> ------------------------------------------------------------------------
>
>
> Ce message entrant est certifié sans virus connu.
> Analyse effectuée par AVG - www.avg.fr 
> Version: 9.0.819 / Base de données virale: 271.1.1/2872 - Date: 05/13/10 20:26:00
>
>

Received on Friday, 14 May 2010 13:01:59 UTC