Wildcard usage

[UlfBj]

In the example in the document Transport-ch. 6.1.22 you find two wildcards in the URL path, see below.
POST /VSS-Root/Cabin/Door///IsLocked HTTP/1.1
This example was derived from a VISS example with a path expression having only one wildcard
"path": "Signal.Cabin.Door.*.IsLocked"
Which from other parts of that example could be understood to represent two path segments having four matches [Row1.Left, Row1.Right, Row2.Left, Row2.Right].

Why do I propose that the one wildcard in the VISS example shall be replaced by two wildcards?

From a client convenience view the alternative with one wildcard seems the preferred, but from a server implementation view the alternative with two wildcards is the preferable.

The server implementation complexity is as I see it significantly increased in the case one wildcard can represent multiple path segments, AND the path expression contains named segments following after the wildcard.

Restricting the wildcard to represent one path segment is not necessary from an implementation complexity point of view when the wildcard is in the last path segment, e. g. “VSS-Root.Cabin.Door.*”.

The obvious argument against this restriction is that it requires the client to have knowledge of the actual tree it is searching. This knowledge is at least available via a service discovery request.

I believe there is a risk with the more complex “multiple segment wildcard” alternative that different server implementations may show interoperability problems.
Hence I think we should select the alternative where a wildcard only represents all possible nodes for one path segment.

In the specification I think a chapter layout as below could be used. I can volunteer to write the wildcard subchapter along proposed choice above.
X. Search mechanisms
X.1. Wildcard
X.2. Query

[peterMelco]

+1

…

On Thu, 6 Dec 2018 at 05:11, Ulf Björkengren ***@***.***> wrote: In the example in the document Transport-ch. 6.1.22 you find two wildcards in the URL path, see below. POST /VSS-Root/Cabin/Door/*/*/IsLocked HTTP/1.1 This example was derived from a VISS example with a path expression having only one wildcard "path": "Signal.Cabin.Door.*.IsLocked" Which from other parts of that example could be understood to represent two path segments having four matches [Row1.Left, Row1.Right, Row2.Left, Row2.Right]. Why do I propose that the one wildcard in the VISS example shall be replaced by two wildcards? From a client convenience view the alternative with one wildcard seems the preferred, but from a server implementation view the alternative with two wildcards is the preferable. The server implementation complexity is as I see it significantly increased in the case one wildcard can represent multiple path segments, AND the path expression contains named segments following after the wildcard. Restricting the wildcard to represent one path segment is not necessary from an implementation complexity point of view when the wildcard is in the last path segment, e. g. “VSS-Root.Cabin.Door.*”. The obvious argument against this restriction is that it requires the client to have knowledge of the actual tree it is searching. This knowledge is at least available via a service discovery request. I believe there is a risk with the more complex “multiple segment wildcard” alternative that different server implementations may show interoperability problems. Hence I think we should select the alternative where a wildcard only represents all possible nodes for one path segment. In the specification I think a chapter layout as below could be used. I can volunteer to write the wildcard subchapter along proposed choice above. X. Search mechanisms X.1. Wildcard X.2. Query — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#284>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMBf_gEKdCrOM3r9WY805wmCMhURem1yks5u2RdvgaJpZM4ZGeqL> .

[wzr1337]

Have you seen how viwi handles these kind of queries?

POST <service>/<resource>/?id=<id1>,<id2> HTTP1.1

{
"Locked": true
}

To lock the elements with IDs and

I strongly recommend not to support wildcards in the url as a client might not even be aware which elements will be actually affected by a change...

* Would mean... Unlock everything.. I do not care.. an unlock on the booth might mean it's jumping open into some obstacle 😉

[UlfBj]

So you say that the request
POST /VSS-Root/Cabin/Door/*/*/IsLocked HTTP/1.1
should be replaced in the mentioned example with four calls as shown below?
POST /VSS-Root/Cabin/Door/Row1/Left/IsLocked HTTP/1.1
POST /VSS-Root/Cabin/Door/Row1/Right/IsLocked HTTP/1.1
POST /VSS-Root/Cabin/Door/Row2/Left/IsLocked HTTP/1.1
POST /VSS-Root/Cabin/Door/Row2/Right/IsLocked HTTP/1.1
Or can you via query expression with $id compress the above into one request call?
Should wildcard usage be allowed in the path when the request goes over WebSockets?
Or do you think that its usage should be abandoned over all transport protocols?

[wzr1337]

Or can you via query expression with $id compress the above into one request call?
Yes, you can combine queries and modifications.

POST <service>/<resource>/?id=<id1>,<id2> HTTP1.1

is similar to

GET <service>/<resource>/?id=<id1>,<id2> HTTP1.1

selecting ALL elements which have their id parameter set to either <id1> or <id2>

combining it with the body:

{
"Locked": true
}

sets the Locked property to true.

The advantage over running multiple queries - which is also possible - is of course that this operation would mean less traffic but even more important either fails or succeeds collectively. So if just one door can not be locked, you get back an error, only if all lock you get back 200 OK.

Should wildcard usage be allowed in the path when the request goes over WebSockets?
No.

Or do you think that its usage should be abandoned over all transport protocols?
I would not allow it in general

Side Note / Disclaimer
Please be aware that I am not a big fan of merging the two protocols, we should rather have a RESTful interface - preferably viwi for all the backend and ECU to ECU traffic.

I would finalize the VSS / VISS spec and make viwi the RSI, make it standard grade and see if it lacks anything I / we have not thought of. Also compare it to GraphQL and see if we could just use GraphQL and abandon viwi / RSI in general if we do not need it. => I do not want to keep it just for the sake of having it.

[PeterWinzell]

So, my take on wildcards is that it could and should be used for subscriptions , that is as for the VISS 1.0 model if that approach is kept. It does complicate the server implementation and we should perhaps add a error statement that could be used by implementations when we violate or pass some performance threshold.

I don't think we should add it to HTTP requests as explained above .

[PatrickCQ]

Short intermediate summary of the current state of discussions:
Groups phone call discussion (https://www.w3.org/2019/01/29-auto-minutes) shows that this issue is closely linked to the location of devices in a vehicle producing data values.
For this a possible solution was presented (https://www.w3.org/2019/02/05-auto-minutes#item02) which was discussed here COVESA/vehicle_signal_specification#81.