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. /js -- 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
