On Fri, Jul 24, 2020 at 2:40 AM Juergen Schoenwaelder < [email protected]> wrote:
> On Sat, Jul 18, 2020 at 09:00:42AM -0700, Andy Bierman wrote: > > On Sat, Jul 18, 2020 at 8:42 AM Vladimir Vassilev < > > [email protected]> wrote: > > > > > On 17/07/2020 21.14, Juergen Schoenwaelder wrote: > > > > > > > - How do we deal with xpath expressions in other encodings > > > > such as JSON. Do we assume an xpath context populated with > > > > module names such that module names can be used to qualify > > > > path expressions. This may need discussion and/or a new > > > > definition. > > > > > > > > - This interacts with the definition of node-instance-identifier. > > > > > > > > - Options: (i) Leave this definition as it is. (ii) Detail how this > > > > type work with encodings that use module names instead of prefixes > > > > to qualify names. > > > > > > > > - Proposal: ? > > > > > > > > > How about leaving the xpath1.0 type definition as it is and specifying > a > > > canonical form for the node-instance-identifier where namespace > prefixes > > > must be module names. > > > > > > > > Since (i) is the only BC option why is (ii) even being considered? > > Of course a new type name is needed to change the XPath syntax > > to something that is not backward-compatible. > > > > The idea was not to propose something non-backwards compatible but to > try to explain how xpath1.0 values work with non-XML encodings. But > perhaps this is 'unexplainable' in the sense that people deal with > this in different ways. > > IMO it is better to use a new type definition where the prefixes MUST be module names rather than overload a widely deployed type definition with semantics that the prefixes MAY be module names. I prefer a new node-instance-identifier typedef, based on RFC 8040 sec. 3.5.3, but that is another discussion. /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <https://www.jacobs-university.de/> >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
