Subject: Re: [alto] Consistent with JSON Patch/Pointer was New error format in draft 20

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 14 Oct 2013 00:19:44 -0400

On Fri, Oct 11, 2013 at 9:20 PM, Y. Richard Yang <[email-masked]> wrote:

> Hi Wendy,
>
> On Thu, Oct 10, 2013 at 10:35 AM, Wendy Roome <[email-masked]>wrote:
>
>> Good point! I was relying on the fact that our field names are unique for
>> now, but there's no guarantee it will stay that way. So yes, set "field" to
>> the full path, and ban "." from field names.
>>
>>  But the path should go all the way to the root dictionary.  Eg, for a
>> bad mode,
>>
>>    "field": "meta.cost-type.cost-mode"
>>    "value": "foo"
>>
>
Suppose we want to be consistent with RFC 6901 and RFC 6902, then we may
name "field" as "path" and use "/" instead of ".". Any comments?

Richard

---

From: Wendy Roome <[email-masked]>
Date: Mon, 14 Oct 2013 14:08:50 -0400

Programming languages use "." to separate components. Unix file systems and
URIs use "/". So is a JSON field name a fully qualified reference in a
programming language, or a full path name in a file system? Is light a
particle or a wave?

I prefer ".", but doesn't really matter to me. And I don't think it's likely
we'll use "." or "/" in field names, so escaping isn't an issue.

Sigh. I just implemented  that. Rather than defining a symbolic constant for
the separator,  I sleazed out and hard-coded ".", thinking that no one would
ever want to change that. Next time I'll learn!

- Wendy Roome

From:  "Y. Richard Yang" <[email-masked]>
Date:  Mon, October 14, 2013 00:19
To:  Wendy Roome <[email-masked]>
Cc:  IETF ALTO <[email-masked]>, <[email-masked]>
Subject:  Re: Consistent with JSON Patch/Pointer was [alto] New error format
in draft 20

On Fri, Oct 11, 2013 at 9:20 PM, Y. Richard Yang <[email-masked]> wrote:
>>  But the path should go all the way to the root dictionary.  Eg, for a bad
>> mode,
>> 

Richard

---

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 14 Oct 2013 15:54:01 -0400

Hi Wendy,

On Mon, Oct 14, 2013 at 2:08 PM, Wendy Roome <[email-masked]>wrote:

> Programming languages use "." to separate components. Unix file systems
> and URIs use "/". So is a JSON field name a fully qualified reference in a
> I prefer ".", but doesn't really matter to me. And I don't think it's
> likely we'll use "." or "/" in field names, so escaping isn't an issue.
>
> Sigh. I just implemented  that. Rather than defining a symbolic constant
> for the separator,  I sleazed out and hard-coded ".", thinking that no one
> would ever want to change that. Next time I'll learn!
>
>
Sorry for the slight change :-) Many of us learnt to not hard code but once
in a while I still do :-)

Thanks!

Richard

> Subject: Re: Consistent with JSON Patch/Pointer was [alto] New error
> format in draft 20
>
>
>> On Thu, Oct 10, 2013 at 10:35 AM, Wendy Roome <[email-masked]
>> > wrote:
>>
>>> Good point! I was relying on the fact that our field names are unique
>>> for now, but there's no guarantee it will stay that way. So yes, set
>>> "field" to the full path, and ban "." from field names.
>>>