Subtopics:
- Wildcards in url (see Transport ch 6.11.2.2)?
- Identical payload on all transports?
- Data model:
o Should all VSS features needed be specified in VSS, or are there W3C specific features to be specified in this spec only?
o At what detail level should VSS be described here?
- Check interface_gen2.html to see what is mentioned here that should be brought into spec docs
o In which document?
o Own chapter, subchapter, or in existing chapter?
- Improvement on current chapter layout?
Ulf: as you know I have created
two documents, core and transport, that was inspired by
conversation at the face to face
... also taking M2M as an influence
... certainly a fair amount of rework will be in order but this
should serve as a starting off point
... for the transport messages I tried to provide
examples
... there are sections brought in from VISS and ViWi
[screen share was on new document and switched over to VISS for wildcard section]
Ulf: I adapted methodology and
maybe worth a separate, more detailed discussion
... path is dot limited and draws from example in ViWi but it
is not very feasible to have wildcards in HTTP URIs
... this seems wrong however do not have a solution
Ted: I don't have a solution either but wonder about using either extra path info or querystring with the wildcards
Rudi: how about having it in the
body?
... path has a different meaning for VSS
Joakim: in sparql you can have a querystring with wildcard in the URL
Mike: multiple wildcards are sometimes supported in URLs
Ulf: that could be a
solution
... path could replace . with /s and always be a 1:1
mapping
Benjamin: you propose a 1:1
mapping of each node, one signals corresponding to a URL and
that differs substantively from the sparql querystring
... I agree having a URI model for VSS would be practical
Joakim: I was just drawing from
sparql on having a wildcard
... it might be able to do filtering
Benjamin: sparql might be a bit computationally heavy but could draw from that model
Ulf: perhaps we should give some thought
Action Ted to create wildcard issue in github
Ulf: in my examples I am
returning the same payload in both access methods
... sometimes you receive redundant information. unsure how
wildcards might cause complexities/differences of wildcard
handling in different transports
... we need to have the method in WSS whereas it is built into
payload
... there is a value to having them identical. a client can be
agnostic to what transport it goes over
Ted: in HTTP there are only headers sent, no request body for GET. POST payload is name/value pairs and PUT can be essentially anything in body
[it might be possible to send a body and HTTP server would ignore, reaction might vary and trigger error]
Ulf: many VISS methods map to HTTP but unsure how to handle case of subscribe
Peter: perhaps we raise this as
an issue in github as well
... with our previous implementation we had some
inconsistencies
... I understand the goal but it might not be attainable
Ulf: you could have $subscribe or $token (to handle auth) within the URI
Ulf: Should all VSS features
needed be specified in VSS, or are there W3C specific features
to be specified in this spec only?
... we have tokens and access restriction model in VISS and
somewhere we need information on which nodes require
token
... that could be placed within the node itself, denoting what
access is required
... it might be difficult to represent adequately in that
context
... but if we do try to represent it there then
Ted:
VISS' getMetaData returns an app the signals it is permitted
(and/or available on vehicle) based on the token, requires app to
handle possibly a subset of what is desired, degrading
gracefully. A given app probably would not even be installed if it
won't be given the bare minimum of needed signals
... having core signals an app can expect to be available, what is
deemed personal identifying information, restriction categories
would certainly be of benefit in setting developer expectations so
there is an argument to expand VSS
Ulf: that is related but also wonder more broadly if there might be other funcationality that we should represent in VSS itself
Rudi: VSS supports notion of an
overlay with additional information being augmented and could
vary for instance by OEM
... we have used that already for representing CAN frames
specific to a manufacturer
Ulf: technically it is possible but it worth clearly specified capabilities coming from the access method?
Rudi: if separate from VSS that could cause some confusion. maybe a custom branch in the same repository that has those extensions
Ted: as noted there are benefits to
having expectations for signal access in VSS, what may be
available without a token for any app.
... in addition to VSS being able to expand, it can also override
and have reduced data
... as to higher level discussion, what should be added into VSS
that might be W3C specific should be considered on a case by case basis
Ulf: we should figure out the appropriate level to expose this information in the main README.md or an alternate for W3C extensions
Daniel: I would prefer one specific document to reference
Benjamin: we discussed
granularity in VSS, we were inspired by WoT thing description and
can have different templates of examples of how to extend
... these extensions might not be restricted to your private
domain but shared
Ulf: my conclusion is we would need to ensure VSS documentation stays in line
Peter: yes, we coordinated with GENIVI extensively for VISS
Ted: we should expect the same as all three maintainers (Rudi, Benjamin and Daniel) of that GENIVI repository are on this call
Daniel: we are open to suggestions as long as there is improvement in the end
Ulf: we should start to look at
the interface document that PatrickL has started. I find it
very good
... we should see how to draw from it and put in these two new
emerging documents
Ted: we should have the benefit of PatrickL next and maybe suggest to him as agenda topic
(or following as me might have too much backlog right after vacation)
Ulf: I would like some guidance on how we handle contributions and coordinate ourselves
Rudi: is that an existing problem, git is well suited as is the github capabilities
Ulf: I think it best to have clear assignments to avoid duplicating effort or have things ignored
Peter: I see your point but
previously it wasn't an issue. the main contributors did the
bulk of the writing
... we did most of the discussion in issues. if there are more
people who want to contribute then we might want more
conventions
Daniel: my suggestion is smaller commits for easier and quicker review, it also reduces conflicts
Ted: feel free to indicate on call or in github issue if you are inclined to write up a proposed solution to avoid duplicating effort. issues that don't reach conclusion or in limbo would become call agenda topics and get discussed and potentially assigned
Daniel: Rudi could you take a look at Ulf's outstanding pull request as we are trying to decide if that belongs on VSS v1 branch
Rudi: Ok
Ulf: parting comment is to encourage others to write
[adjourned]