On Jan 12, 2005, at 3:21 PM, Julian Reschke wrote:
> Ben Collins-Sussman wrote:
>> On Jan 12, 2005, at 1:01 PM, Greg Stein wrote:
>>>
>>> RFC 2518, section 12.10 states that the DAV:owner element can
>>> contain any
>>> XML child elements. IOW, it is structured data rather than a simple
>>> string
>>> (see the example in section 8.10.8). Therefore, mod_dav serializes
>>> that
>>> into a string and stores it into the ->owner field.
>> Sure, <DAV:owner> can "contain" any amount of structure. So why
>> isn't mod_dav saving just those structured contents? Why is it
>> *also* saving the <DAV:owner> tag? Isn't that a bug?
>
> It's probably the easiest way to also preserve namespace declarations
> and attributes (our server internally does the same).
>
That just doesn't make sense to me or cmpilato.
It seems totally wrong for a client to use the <DAV:owner> as a place
to store attributes and private namespaces that apply to the tag's
contents. Clients that do this are placing a ridiculous burden on DAV
servers, no? If the client demands that the server preserve these
namespaces outside of the content, then the server should be able to
"push" the namespaces down into the content when convenient. But then
on the other hand, the server is supposed to treat the content
opaquely... so it can't assume the content is XML.
What if the <DAV:owner> content is using namespaces defined 2 levels
up? Does the server have to preserve those namespaces too? Where do
we draw the line?
Does MS Office really behave this way and make these demands?
Does RFC2518 really allow clients to attach arbitrary junk to
<DAV:owner>?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 12 23:01:44 2005