Hi Wendy, On Mon, Oct 14, 2013 at 2:08 PM, Wendy Roome <[email protected]>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 > 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! > > Sorry for the slight change :-) Many of us learnt to not hard code but once in a while I still do :-) Thanks! Richard > - Wendy Roome > > > From: "Y. Richard Yang" <[email protected]> > Date: Mon, October 14, 2013 00:19 > To: Wendy Roome <[email protected]> > Cc: IETF ALTO <[email protected]>, <[email protected]> > 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 protected]> wrote: > >> Hi Wendy, >> >> On Thu, Oct 10, 2013 at 10:35 AM, Wendy Roome <[email protected] >> > 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 > >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
