Re: Decoupling between Link and its mediatype, and inputData/outputData

This makes no sense from the WWW architecture point of view.

https://www.w3.org/TR/webarch/#frag-coneg

On Mon, Sep 25, 2017 at 3:12 PM, Kaebisch, Sebastian <
sebastian.kaebisch@siemens.com> wrote:

> Dear all,
>
>
>
> in my point of view we need 4 resources to fulfill Maxime’s use case:
>
>
>
> {
>
>   “interaction”: [
>
>     {
>
>       “@type”: “Property”,
>
>       “link”: [
>
>         { “href”: “http://192.168.0.10/property”, “mediaType”:
> “application/xml” },
>
>         { “href”: “http://192.168.0.10/property”, “mediaType”:
> “application/json” },
>
>         { “href”: “http://192.168.0.10/property.xml”, “mediaType”:
> “application/xml” },
>
>         { “href”: “http://192.168.0.10/property.json”, “mediaType”:
> “application/json” }
>
>       ]
>
>     }
>
>   ]
>
>   …
>
> }
>
>
>
> Since a duplicated resource is provided with different media types the
> Accept field has to be used at runtime. The question is whether this is
> practical and can we be more compact.
>
>
>
> @Maxime: I’m not sure if I understand the point correctly why you need two
> dataShema definitions for the same data content of the Property. Actually,
>  you need only one for defining XML- and JSON- based payload. Also see [1]
> and [2].
>
>
>
> Best regards
>
> Seb
>
>
>
> [1] https://www.w3.org/TR/wot-thing-description/#structured-data
>
> [2] https://www.w3.org/TR/wot-thing-description/#mapping-to-xml-schema
>
>
>
>
>
> *Von:* Charpenay, Victor [mailto:victor.charpenay@siemens.com]
> *Gesendet:* Montag, 25. September 2017 10:38
> *An:* Dave Raggett; Maxime Lefrançois
> *Cc:* public-wot-wg@w3.org
> *Betreff:* RE: Decoupling between Link and its mediatype, and
> inputData/outputData
>
>
>
> Hi Maxime,
>
>
>
> in the situation you are describing, aren’t the three URIs a bit
> redundant? To access the content of your Property, I assume that a client
> has to understand HTTP semantics (specificed in RFC 7231, which defines
> e.g. how to interpret Content-Location). This means that it should be able
> to perform both a simple GET on the XML or JSON resources (without content
> negotiation) and a GET with content negotiation on the generic resource. In
> this sense, declaring all resources would require that your TD redefines
> the semantics of HTTP content negotiation, somehow.
>
>
>
> In my opinion,  you should choose one of the two options (with or without
> content negotiation), as presented below. Your choice might depend on how
> likely it is that your servient will support new content types in the
> future. With the first option, you will have to update your TD every time
> it occurs.
>
>
>
> That said, I also met the case where I wanted to declare required custom
> HTTP header fields in a TD. I finally decided to use the HTTP RDF
> vocabulary (http://www.w3.org/2011/http). With respect to content
> negotiation, if you want to give clients a hint on the media types your
> servient supports in the TD, you could also use this vocabulary. What do
> you think?
>
>
>
> (By the way, Dave, the first choice you presented has the drawback that
> non-standard extensions, such as custom HTTP header fields, could not be
> declared in a TD.)
>
>
> ------------------------------
>
> {
>
>   “interaction”: [
>
>     {
>
>       “@type”: “Property”,
>
>       “link”: [
>
>         { “href”: “http://192.168.0.10/property.xml”, “mediaType”:
> “application/xml” },
>
>         { “href”: “http://192.168.0.10/property.json”, “mediaType”:
> “application/json” }
>
>       ]
>
>     }
>
>   ]
>
>   …
>
> }
> ------------------------------
>
> {
>
>   “interaction”: [
>
>     {
>
>       “@type”: “Property”,
>
>       “link”: [
>
>         { “href”: “http://192.168.0.10/property”, “mediaType”:
> “application/*” }
>
>       ]
>
>     }
>
>   ]
>
>   …
>
> }
> ------------------------------
>
>
>
> Regards,
>
> Victor
>
>
>
> *From:* Dave Raggett [mailto:dsr@w3.org <dsr@w3.org>]
> *Sent:* Freitag, 22. September 2017 19:12
> *To:* Maxime Lefrançois
> *Cc:* public-wot-wg@w3.org
> *Subject:* Re: Decoupling between Link and its mediatype, and
> inputData/outputData
>
>
>
>
>
> On 22 Sep 2017, at 14:11, Maxime Lefrançois <maxime.lefrancois@emse.fr>
> wrote:
>
>
>
> Dear all,
>
> The decoupling between Link and its mediatype, and inputData/outputData,
> makes me having some trouble trying to model the following situation:
>
> Suppose a device exposes the same information in xml or json, using
> content-negotiation, at http://192.168.0.10/property
> - the xml version has a canonical URL http://192.168.0.10/property.xml
> (see also Content-Location)
> - the json version has a canonical URL http://192.168.0.10/property.json
>
> I'd like to model this situation with a single device, a single
> td:Property, three td:Link, and only two td:DataSchema objects.
>
> How would you suggest to manage this ?
>
>
>
> I don’t full understand the question.
>
>
>
> The object model for the property should be the same regardless of whether
> the interaction model is described in JSON, JSON-LD or RDF/XML, e.g. the
> property could be a integer.
>
>
>
> Perhaps you are talking about the case where the messaging protocol for
> property updates supports multiple data formats. The communications
> metadata needs to clarify which protocols and data formats can be used.
>
>
>
> I see two broad choices:
>
>
>
> 1. The communications metadata references a standard and provides any
> additional parameters as needed for using that standard. This assumes
> drivers that embed knowledge about these standards, e.g. a driver for Apple
> HomeKit, a driver for Bluetooth, or a driver for OCF.
>
>
>
> 2. The communications metadata provides a declarative means to express a
> broad range of possible approaches using well known protocols.  This
> results in much more complicated thing descriptions, but the premise is
> that a complex generic driver is worth the extra complexity compared to
> needing drivers specialised to particular standards. Given the wide variety
> of possible ways of laying standards on top of core protocols, we are
> unlikely to provide a fully general solution.
>
>
>
> Making our assumptions explicit would increase our chances of success.
>
>
>
> Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
>
> W3C champion for the Web of things & W3C Data Activity Lead
>
>
>
>
>
>
>
>
>