> My assumption: a client cannot create a media resource without also
> creating a media link entry. When I POST a media resource to a
> collection, a media link entry is *always* created.
Same here. Lisa what do you mean by creating a media resource manually?
If you do not use an APP service t
Hi,
RFC4287 distinguishes between 'undefined' and 'extension' constructs.
I am understanding the distinction to imply that conformant software
should provide for handling extension elements, but can and should
ignore any occurrences of undefinedAttribute or undefinedContent.
Is that unde
James M Snell wrote:
Lisa Dusseault wrote:
Explicit result of POST, section 4.
Are there zero, one or more resources created with a POST? There's a
line at the top of section 4 which says that "POST is used to create a
new, dynamically-named, resource". However, that implies ONE, whereas
wit
* Jan Algermissen <[EMAIL PROTECTED]> [2006-10-18 10:45]:
> RFC4287 distinguishes between 'undefined' and 'extension'
> constructs. I am understanding the distinction to imply that
> conformant software should provide for handling extension
> elements, but can and should ignore any occurrences of
On 18 Oct 2006, at 01:40, James M Snell wrote:
[snip]
The spec says "The value of atom:updated is only changed when the
change
to a member resource is considered significant. " The use of passive
voice obscures who does what here. When the client doesn't suggest a
value for "atom:updated",
Many thanks to Lisa for the lengthy and detailed comments. I am just
replying to those comments relating to the parts of the spec I
understand best.
On 18 Oct 2006, at 01:40, James M Snell wrote:
*Synchronization*
I predict that some AtomPub authoring clients will attempt to
synchronize:
No, it means only that it's the server's responsibility to determine
when atom:updated should be updated and when it shouldn't. If the
server wishes to delegate that responsibility to the client, then that's
fine.
- James
Henry Story wrote:
> [snip]
> Completely disagree.
> If the server contro
On 18 Oct 2006, at 16:10, John Panzer wrote:
My assumption: Tim is correct. The server controls
atom:updated. While
the client is required to provide a valid atom:updated element, the
server can (and in most cases will) ignore that value.
Completely disagree.
If the server con
2006/10/18, A. Pagaltzis:
* Jan Algermissen <[EMAIL PROTECTED]> [2006-10-18 10:45]:
> RFC4287 distinguishes between 'undefined' and 'extension'
> constructs. I am understanding the distinction to imply that
> conformant software should provide for handling extension
> elements, but can and shou
On 18 Oct 2006, at 16:34, James M Snell wrote:
No, it means only that it's the server's responsibility to determine
when atom:updated should be updated and when it shouldn't. If the
server wishes to delegate that responsibility to the client, then
that's
fine.
Is this not splitting hairs a
I think it is important in order to make the distinction between whether
the server MUST, SHOULD or MAY accept the atom:updated value provided by
the client. I would argue that it needs to be a MAY with a clear
statement that allowing the client to set the value is quite likely
going to be very u
11 matches
Mail list logo
