+1
On Tue, Jan 8, 2013 at 10:13 AM, Jared Rosoff wrote:
> my bad.
>
> regardless, if you want to replace the whole document, is that a patch? or
> should that better be done with PUT?
>
>
> On Tue, Jan 8, 2013 at 9:58 AM, James M Snell wrote:
>
>>
>>
&
On Tue, Jan 8, 2013 at 9:52 AM, Jared Rosoff wrote:
> [snip]
> then it would result in the document after patch being
>
> [1,2,3]
>
> however, this is not a valid json document as it is not enclosed by { }.
> [snip]
>
The root of a JSON Document can be either an object or an array.
- James
Fortunately the JSON-Patch syntax is designed such that it is possible to
extend the range of defined operations without breaking basic structure...
much as I have done with the json-predicates draft. You would need to
define a new media type to associate with the extensions but that's not
difficul
If I may, I would follow this up with a suggestion that a separate I-D that
provides a more complete treatment of fully-concurrent patch operations
would be helpful. JSON-Patch is largely designed around atomic and
sequential modification operations and is not, necessarily a great match
for the kin
s spec is done and ready to go.
- James
On Jan 5, 2013 9:25 PM, "Robert Sayre" wrote:
> On Sat, Jan 5, 2013 at 8:55 PM, James M Snell wrote:
> >
> > On Jan 5, 2013 8:20 PM, "Robert Sayre" wrote:
> >>
> >> On Sat, Jan 5, 2013 at 6:59 PM, Mark
y think that people PATCHing
something as if it's an array (when in fact it's an object) is a
significant, real-world problem, given that the patch author already has to
understand the semantics of the document they're patching? I don't, and the
WG didn't eit
tthew Morley wrote:
> >>> I am usually lurking and struggling to keep up with these posts. But, I
> >>> concur with James, this really is a non-issue in practice.
> >>>
> >>> The JSON Pointer expresses a path down a JSON object to a specific
> c
What I'm not clear on, however, is what significant benefit making this
kind of change would provide. Yes, the syntax can be more verbose and exact
but it's not clear that the change is worth the cost.
Robert mentioned that the addition of the json-predicates test doubled the
size of the json-patc
tion case where it's
been an issue (that's not to say they don't exist, just haven't seen it in
practice yet). What's your suggestion for making the syntax better?
On Mon, Dec 17, 2012 at 7:41 PM, Robert Sayre wrote:
> On Mon, Dec 17, 2012 at 7:08 AM, James M Sne
to make the patch format more precise?
> >>
> >> - Rob
> >>
> >> On Sun, Dec 16, 2012 at 4:33 PM, Matthew Morley wrote:
> >>> I am usually lurking and struggling to keep up with these posts. But, I
> >>> concur with James, this really is a
xt before applying a patch,
> this should probably be part of a test operation. I'm not sure if this is
> possible at this point (?), but that is where the logic should exist.
>
>
> On Sun, Dec 16, 2012 at 12:22 AM, James M Snell wrote:
>
>>
>>
>>
>> On Sa
dge in advance what they
are modifying. The only time the apparent ambiguity becomes an issue is
when a client is blindly sending a patch to an unknown endpoint... in which
case, you get whatever you end up with.
- James
> - Rob
>
>
> >
> > --
> >
> > Markus La
The author just needs to be aware of the current state of the object being
patched. Using conditional requests mechanisms can make it more reliable.
On Fri, Dec 14, 2012 at 9:38 AM, Markus Lanthaler
wrote:
> On Friday, December 14, 2012 6:19 PM, James M Snell wrote:
>
> > > On Fr
; --
>
> Markus Lanthaler
>
> @markuslanthaler
>
> ** **
>
> ** **
>
> ** **
>
> *From:* James M Snell [mailto:jasn...@gmail.com]
> *Sent:* Friday, December 14, 2012 5:41 PM
> *To:* Markus Lanthaler
> *Cc:* IETF Discussion; IETF Apps Discuss
> *S
JSON Pointer does not distinguish between objects and arrays. That is not
determined until the pointer is applied to an actual object instance... the
pointer "/1" is valid against {"1":"a"} or ["a","b"]
On Fri, Dec 14, 2012 at 2:51 AM, Markus Lanthaler
wrote:
> I've asked that before but didn't
You are reading it correctly. Note also that the very next bullet point
says:
A member to add to an existing object - whereupon the supplied
value is added to that object at the indicated location. If the
member already exists, it is replaced by the specified value.
So an "add" is really a
It should be quite clear to everyone that the horse is quite dead at this
point. Any further beating is entirely unnecessary. So let's wrap it up
with this: the whatwg's spec language around urls has the potential to
cause confusion among implementers, so please consider reworking that
language to
On Mon, Oct 22, 2012 at 3:35 PM, Ian Hickson wrote:
> On Tue, 23 Oct 2012, Jan Algermissen wrote:
> >
> > The point is that what you and Anne are addressing is parsing of URI
> > *References* not URIs.
>
> Anne's spec defines how you get from any arbitrary string (plus a base
> URL) to a data str
client
> and server.
>
> And maybe:
>
> As with other preferences, the wait preference could be ignored.
> Clients can abandon requests that take longer than they are
> prepared to wait.
>
> --Martin
>
> On 5 October 2012 11:28, James M Snell wrote:
> > How
11:12 AM, Martin Thomson wrote:
> On 5 October 2012 10:42, James M Snell wrote:
> > I could drop the Date header recommendation altogether and stress in the
> > text that good clock synchronization and predictable latency is required
> for
> > the wait preference to be
I am certainly open to alternatives on this particular point. The wait
preference has proven to be quite useful in environments where the latency
is low and predicable and there is good clock synchronization between the
client and server. Such conditions can be easily achieved when the
deployment e
you and others have pointed out,
(x)html has no similar notion and a direction has to be assumed. The
main point of dir="" is to ensure that the original directional context
of an entry is preserved regardless of the specific feed that happens to
contain the entry.
- James
Frank Ellerman
My apologies for not getting back to this sooner. Comments below.
Frank Ellermann wrote:
> James M Snell wrote:
>
>> If another version of the draft is needed based on
>> last-call comments, I can make the name change then.
>
> Leave it alone, please. Various to
The dir="" is not really intended to specify that the direction is not
known but that the direction has not been specified explicitly. For
instance, in an aggregate feed containing entries from multiple sources,
the original entries may or may not have contained the bidi attribute.
Because of
The "atompub" was originally in reference to the Atompub Working Group.
Now that the WG is closed, it probably would make sense to change this
to just atom. If another version of the draft is needed based on
last-call comments, I can make the name change then.
- James
Tim Bray wrote:
> On F
While it is definitely true that there has been a lot of good feedback,
it would still be good to at least start broadening the net and get
feedback from the larger IETF community.
- James
Julian Reschke wrote:
> [snip]
> + 0,5.
>
> The document got lots of constructive feedback in the previous
The Apache Abdera project [1] has implemented partial support this
specification. We've seen no significant issues other than, perhaps, a
limited number of available implementations and feed instances to test
against. FWIW, I think moving this forward on the standards track is fine.
- James
[1]
Julian Reschke wrote:
> [snip]
> Well, maybe the members of the working group want to consider to have
> the protocol published somewhere else (remember there was a big
> discussion about W3C vs IETF before this working group was formed?).
>
-1. At this point switching venues would be positivel
wrote:
> James M Snell wrote:
>
>> a primary goal of mine is to remain consistent with rfc4287.
>
> Hi, I've seen the "post last call" update (draft -08) triggered
> by the GenArt review, where you say "are not legally binding".
>
> How about "
Frank Ellermann wrote:
> James M Snell wrote:
>
>> let me know if this is an improvement
>
> Hard to judge, now that I know what it's supposed to
> do it's "obvious"... :-) I think it's clearer now:
>
;-)
> Jane's feed is "by
Ellermann wrote:
> James M Snell wrote:
>
>>> how about s/IRI/URI/ ?
>
>> Whenever RFC4287 says "atomUri" it means IRI. I understand
>> what you're saying, but the value of the href value may, in
>> fact, be an IRI.
>
> The only case whe
Frank Ellermann wrote:
> [snip]
>> An analogous scenario is when I distribute some piece of open
>> source software under the Apache license. The zip I
>> distribute contains the ASF LICENSE file. It also happens to
>> contain jars for a number of dependencies from other
>> projects, all of whic
Frank Ellermann wrote:
> The IESG wrote:
>
>> - 'Atom License Extension '
>>
>
> | Licenses associated using these mechanisms MAY or MAY not be
> | machine readable
>
> Isn't "MAY" always the same as "maybe not" ? I'd read a "MAY
> or MAY not" as "maybe not or maybe", and in that case I
33 matches
Mail list logo
