Joe Gregorio wrote:
I think that is fine, another constaint I would add to the
one I already proposed is that every client should be
able to handle every type of Text Construct.
[snip]
> Agreed. I believe the server is allowed to modify the entry
> to fit the local requirements (unless it can advertise ahead
> of time it will reject such content).
So it would not be ok for a server to reject content it doesn't support
but it is ok for the server to transform it into something else entirely
even if it means losing data? Either way, it's a good idea for the
client to know up front what's likely to happen. So no matter how you
look at this argument, both sides are lean in favor of some kind of flag
in the introspection doc.
> [snip]
This is not a slippery slope. We have an interop problem
and the stop criteria is very simple; we stop adding
constraints when the interop problem goes away to the
WG's satisfaction.
The slippery slope comes into play when we start getting into a debate
what constraints need to be added to ensure interop and try to
micromanage what a server MUST or MUST NOT reject. It goes away
completely if we simply allow the server to deterministically declare
what it can or cannot do in the introspection document and leave it up
to the client to adjust its behavior accordingly. Clients that don't
adjust will simply have to learn how to put up with status codes like
403, 422 or markup-laden titles that are suddenly stripped of their
richly-formatted goodness.
[snip]
problem. If you have other suggestions; besides ignoring
the problem which I don't believe is a legitimate option,
I would very much like to hear them.
I'm not arguing against what you're proposing and I most certainly am
not ignoring it. I've proposed the same thing in the past and the WG
hasn't gone for it. Something about YAGNI, or that's what http status
codes are for, or some such...
- James
