<scribe> scribenick: ted
<scribe> Scribe: Ted
PatrickL: queries and phonebook registry are our two primary topics for today
UNKNOWN_SPEAKER: what do we need
and what do we want for certain data elements
... example would be to provide all doors with side attribute
left or all windows that are open
... please speak up about what you want for queries, whether we
need them
Glenn: yes, queries would be very
helpful and as you described
... as a fleet manager also speed, diagnostics...
PatrickL: not thinking specific
queries but to ask for certain range of values or value
itself
... do I need a <, > or =
... what type of comparison mechanisms are needed
... of course I want to be able to query on a value
object
... do we need and and or contatentation?
... can someone explain querying in VISS?
Ulf: we should strive for an API
that is as helpful as possible for developers who will use it
and queries certainly will do that
... provided the complexity of its use does not exceed the
usefulness
Laurent: I agree with Ulf, they
do bring complexity when you think about runtime behavior
... processing power, number of concurrent
applications/queries
... an API can allow local queries where they can process on
the client side
... this offloads some of the cost from the server to client,
we should handle both models
... I have not answered the type of query we want however
PatrickL: sometimes you want to be precise with the data being returned, others access raw data and analyze or filter on client side
Laurent: the developer should not care how, in fact they would prefer consistency on both local and remote queries
PatrickL: I could imagine when you can either process a complex query server side or if more efficient return the full results and have client handle it
Laurent: I want the option to
distribute. if you have a server centric approach you put
strain
... sometimes you want to reduce dataset to be easier to
process
... it depends on the capabilities you want to offer. I don't
think we want something like SQL, XPath is a de facto but
perhaps overly complex
... I use to do more embedded programming. if bandwidth isn't
an issue and I have a more capable client device I want to
receive more data
... server side reduces traffic when throughput is an issue or
limited client capabilities
PatrickL: that makes sense to
me
... what Ulf said in the beginning is you have to have in mind
query complexity
... developers would like the possibility of offloading
processing where it makes sense
... I will expand comparison functions in the wiki and others
welcome to add
... were there functions you had in mind?
Laurent: some times you will run a query remotely, regularly
PatrickL: are you interested in
sorting?
... I might want to get a list of all media tracks by a certain
artist and then order them by length
Laurent: in sql you have your select statement, what you want and then how to group or sort
Paul: wildcarding is not a
query
... when you are talking about something moving by on the wire
like signals it is very different
... in VISS there is a service and you want a piece of data
from the tree, you subscribe to certain data elements which is
not quite a query
Laurent: that is like XPath
... you query on a path but you can do more with XPath, remove
branches you don't want and be selective based on
attributes
Paul: I was trying to
characterize the differences and which is more suitable
... how much the data is changing matters as well
Laurent: I can see mapping XPath queries to VSS whereas it lacks some of the querying capabilities of SQL
https://www.w3.org/TR/vehicle-information-service/#server-side-filtering
Ted: in VISS you can subscribe to a subset of the tree you want to follow and then apply filters on eg frequency or delta change when you want updates from the server
Laurent: you described the two main things we want, tell me where the data is and how to filter
PatrickL: in VISS you might be looking for a certain attribute, you would request all elements via wildcard that have a certain attribute
Paul: media example is static
data whereas signals are highly transient
... SQL type queries work with large amounts of semi-static
data. it is more pre-coordinated and you know the data
structure
... the other approach, for transient, your questions may vary
and the structure might not be as you expected
PatrickL: I feel we need to be
able to handle both types of data
... both should be possible with the same type of interface
connection
Paul: there are things in between
as well. I am not sure about a one size fits all approach
... it depends on how data is being written
PatrickL: we need to find the sweet spot. either we have a set of capabilities to handle the data or we create capabilities description like Laurent was alluding to
Laurent: instead of service,
let's just say data source
... interestingly are we targeting developers that want to
handle massive static or transient data?
... if you think about the android apps to entice you to drive
better and reduce your insurance. it seems to be larger,
historic data
Ted: given the sheer volume of data available in my opinion you will want an application with sampling logic being selective instead of trying to create a sizable onboard datastore you can query
Paul: roundripping data to
servers like Sensoris
... they sift data, send to cloud and have historic value
available
Laurent: so we want to enable collecting data for historic datasets without providing it?
Paul: typically for signals you are talking about discrete bits of data flowing on CAN bus
Laurent: do we want a single API for all these domains? there is tension between them
Ted: ideal would be consistent for sake of developer, make it intutive but indeed a challenge
PatrickL: I see potentially two different implementations but ideally using the same methodology/framework
Laurent: it is interesting to
have in mind 4k soundtracks with lots of information but they
don't change much versus small bits of rapidly changing
data
... the information flow is key. having the same methods of the
collector
PatrickL: I will do a writeup of
this discussion to add to the wiki
... I will ask for review on the mailing list
https://www.w3.org/auto/wg/wiki/VISS-RSI-convergence-framework