Draft: draft-ietf-jsonpath-base

Commentary: Fixes 
 is a subtype by coercion of , but Table 13 does not include this subtype relationship . 
 Not sure I like the concept of " subtype by coercion " . One can be used in place of the other as it can be coerced , but that is not usually what we 'd call a subtype . 
 That 's a different point really . Table 13 already includes at least one subtype by coercion , so this issue adds another subtype by coercion . 
 How would you like to proceed with " subtype by coercion " ? If we want to explore alternatives , I think it deserves a separate , non - editorial issue . 
 From the spec , just below : I disagree with the idea that coercion implies subtypes . If I have integer and floating point numeric types , I can cast from one to the other , but that does n't mean that either is a subtype of the other . C # provides " implicit " casts where the compiler can infer a type cast from context . For example , I think this is closer to what we 're dealing with here . We 're looking at compatibility and conversion between types , not polymorphism ( as " subtype " implies ) . 
 If I 'm reading the right , it looks like the term is being used to mean different things depending on which column it 's in . In column 1 ( " Type " ) or column 3 ( " Subtypes " ) , it 's referring to the type system we 're creating . In column 2 ( " Abstract Instances " ) , it 's referring to the underlying JSON(ish ) value kind , i.e. , , , etc , plus . I think having the same word to define these things can be confusing for the reader , and maybe we need something else in one of these places to indicate the distinction . We 've already done this for the type to distinguish it from the value . 
 I 'm not sure there is a really good alternative . We could use for abstract instances , but in the rest of the spec , " value " implies a JSON value , so this does n't seem quite right . 
 If " value " implies a JSON value ( corresponding to the middle column ) , then we should change the others ( the type name ) . It really is confusing . 
 In the interim , we decided to append the type names with " Type " . I will create a PR for this . 
 I 'm going to wait for to complete before going forward with this as they change the same chunk of text . 
 Thanks . That 's why I am trying to tidy up and get it merged ASAP . 
 ( Modulo the coercion entry on OptionalValue , as discussed . )
Paragraph (version A):
A type is a set of instances.  A type is a subtype of another type if
its set of instances (possibly after coercion) is a subset of the set
of instances of the other type.
Paragraph (version A):
tbl-types defines the available types in terms of abstract instances,
where "n" denotes a node, "v" denotes a value, and "nl" denotes a
non-empty nodelist.  The table also lists the subtypes of each type.
Paragraph (version B):
A type is a set of instances.  A type is a subtype of another type if
its set of instances (possibly after coercion) is a subset of the set
of instances of the other type.  The subtype relationship is
transitive: for any A, B, and C if B is a subtype of A and C is a
subtype of B, then C is a subtype of A.
Paragraph (version B):
tbl-types defines the available types in terms of abstract instances,
where "n" denotes a node, "v" denotes a value, and "nl" denotes a
non-empty nodelist.  The table also lists the (immediate) subtypes of
each type.