Re: YPath question

On Mon, Oct 24, 2011 at 10:29 AM, Ingy dot Net <[email protected]> wrote:
> 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?
>

That's an excellent question.

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:

---
{key: 2002-12-14}
...

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
YPath).

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.

> 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.
>
> pair:
> - !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?

Now that's a tricky problem to resolve. One way is for YPath to allow
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
rationals.

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,
utf-8) text.

Best regards,
Peter

-- 
Email: [email protected]
WWW: http://www.pkmurphy.com.au/

------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
Yaml-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/yaml-core