On Mon, Oct 24, 2011 at 2:50 AM, Peter Murphy <email@example.com> wrote:
On Mon, Oct 24, 2011 at 10:29 AM, Ingy dot Net <firstname.lastname@example.org> wrote:That's an excellent question.
> I have a question about the intent of something that I consider important to
> determining for YPath:
> If a YPath query is applied against a YAML representation graph, has
> implicit typing been performed or not?
I assumed (but did not write in the specification) that implicit
typing would be done for scalars, to use the full power of the tag
reposititory at http://yaml.org/type/. For something like this:
I assumed "key" is a string of tag !!str, and "2002-12-14" is a
datetime with tag !!datetime. The latter could then be the target of
predicates like "[later than] 2001-01-01" (however it is expressed in
However, users may expect it to be a string. Datetimes are not
contained in the failsafe schema nor the JSON schema of the YAML spec.
To repeat: that's an excellent point to bring up, and it has to be
handled by the spec. YPath should allow users to select how implicit
their tag resolution should be.
Now that's a tricky problem to resolve. One way is for YPath to allow
> I'm not sure if this has even been considered yet. And I'm not sure if we
> have to make a decision one way or another. But it's worth discussing.
> Consider this example.
> - !rational
> numerator: 1
> denominator: 3
> - !rational
> numerator: 17
> denominator: 7
> This a pair of rational numbers, but they are represented as a mapping of
> numerator and denominator. So we might want to find numbers greater than 1,
> or we might want mappings whose numerator is less than 10.
> I will assume they YPath queries may wish to be made against a serial YAML
> stream, or against Native in memory data structures. In the former case we
> need to compose the representation, and in the latter we need to represent
> it. Where does type transforming and detransforming happen and how we tell
> YPath how far to go?
users to extend the language by their own custom predicates (e.g.
rational_less_than), and then allow the code for the predicate to be
called by the processor as necessary.
But it would be more aesthetic to have the less_than predicate (which
will be part of the core - it's too useful) to be _extended_ to handle
A third option is to not allow YPath to be extended in any way. But I
would rather not do that!
It's a tough one. Thoughts?
I should add that I have been playing around with AsciiDoc, and I like
it. I'll try to get the next spec of YPath written it it. It's easier
for people to revise different versions when they're "plain" (well,