Agenda Planning

From Auto

This is a prioretized list of upcoming topics in the working groups calls. Priority may be changed in group calls or via discussion on the mailing list.

Notes may and shall be added by all participants to share these within the group.


  • queries
    • Discussion: https://www.w3.org/2018/05/29-auto-minutes
    • it is part addressing the data in question, part filtering for a certain set of data
    • filtering
      • we want to be able to ask for "all doors which are open"
      • problem: to much work for source implementation possible if to much possibilities to structure a query
      • use of resources on service side might be limited
      • idea: service can "tell" what kind of filter/query possibilities are offered. Client may solve the rest
      • capabilities for filtering might be depending on implementation. expected data amount vs. complicated implementation
      • filtering shall be possible on every value which is "easily describable" (e.g. binary blobs might not be filterable)
      • Other solutions
        • xpath
        • SQL
  • registry / list of resources / list of services
    • extensible at run time?
  • introduction of clusters
    • to reduce "complexity"
    • handle a bunch of objects as a "collection" with a certain version
  • Target Group
    • Discussion: https://lists.w3.org/Archives/Member/member-automotive/2018May/0031.html
    • internal functions main focus for the framework
    • make information from the vehicle available to developers
      • These developers might be 3rd party developers
    • framework primarily for developers as they should have it as easy as possible to interact with the vehicle.
      • It would be cool if 3rd party apps could offer something in the same manner as internal functions are offering information (extensibel)
  • distributed Implementation of vehicle interfaces
    • Discussion: WG Call 2018-05-22
    • created from discussion topic "micro services"
    • distributed implementation of services implementing the APIs should be possible
    • distributed implementation could have an impact on the possibilities of queries
  • Versioning
    • having version clusters of version clusters
  • addressing data
    • what should be addressable
    • how should an address look like
  • payload encoding (JSON, JSON-LD, . . .)
  • element handling
    • object oriented
    • interlinking the objects
  • grouping (signals and resources)
    • Discussion: WG Call 2018-05-22, still not finished as group asked for an example
    • Data values shall not be buried for developers, it shall be logical from a developers point of view (Data Value)
    • Data values shall be easily structure into a rough object like approach (Object)
    • Similar objects shall be grouped by a context (Cluster)
    • Example:
      • Cluster: Body
        • Object: Window (or List of windows)
          • data value: position
          • data value: dirty
        • Object: Doors (or list of doors)
          • data value: locked
          • data value: closed
          • data value: window