peterMelco
commented
5 years ago +1
On Thu, 6 Dec 2018 at 05:11, Ulf Björkengren notifications@github.com 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 https://github.com/w3c/automotive/issues/284, or mute the thread https://github.com/notifications/unsubscribe-auth/AMBf_gEKdCrOM3r9WY805wmCMhURem1yks5u2RdvgaJpZM4ZGeqL .
wzr1337
UlfBj
PeterWinzell
PatrickCQ
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