Re: YPath question

On Mon, Oct 24, 2011 at 2:50 AM, Peter Murphy <[email protected]>wrote:

> 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?
>

My gut feel is this: Let YPath apply to a given representation in a given
state, but not be concerned about how it got there. You should leave the
transitioning and type resolution application to another mechanism or yaml
language.

This will keep YSpec simple and useful, and also drive the need for a simple
and useful YAML transformation language.

Even in the absence of a transformation/representation language, this is
probably the way to go. You can fake it by configuring the dumper in such a
way that you get a representation that make sense for your YPath query.



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

Great. One further suggestion... Now that you have a spec in plain text,
please make a GitHub repo for it. GitHub gives you so much. Issue tracking,
wiki, forking, pull requests, dozens of features I haven't even tried, but
most importantly a huge community of followers and collaborators.

Git/GitHub is simple but let me know if you need any help.


>
> 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