Re: YPath question

Ingy,

I believe I announced a GitHub repository for YPath here.

https://github.com/peterkmurphy/YPath-Specification/

As stated, it was saved as an .odt file. However, I would like to save
it as AsciiDoc, so that it can more easily be branched and merged.

Best regards,
Peter

On Tue, Oct 25, 2011 at 2:08 AM, Ingy dot Net <[email protected]> wrote:
> 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/
>
>



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