Re: Status of Bugzilla Bug 10, Round-tripping various information in properties

On Dec 23, 2005, at 7:33 AM, Geoffrey M Clemm wrote:

> Lisa wrote on 12/23/2005 09:42:01 AM:
>
> > Wilfredo points out something I hadn't considered before, which I  
> think
> > addresses your concern, Geoff -- the idea that the only agents that
> > need to preserve prefixes are those that want to.
>
> My point below was that this is precisely what an agent cannot do
> (if by "agent", you mean an individual client).  One agent cannot
> decide to preserve prefixes by escaping the XML for a given
> property value, unless *all* agents have agreed to do so (i.e.,
> unless that property by definition always holds escaped XML text).
>
> So at a minimum, you can never use this approach for an existing
> property, because none of the existing clients will be escaping the
> property value on write or unescaping the property value on read.

   Correct, but the existing spec (which is what applies to existing  
properties) doesn't require prefixes to be preserved.  You can't fix  
that with a spec change after the fact.

> >   - Currently we have no known servers or clients that have a  
> need to
> > preserve prefixes.
>
> I'm not sure who "we" refers to here, but minimally it doesn't include
> us (:-), because we will store XML schema and XSLT data in property  
> values,
> which do require that namespace tags be preserved.  I doubt we're the
> only ones that will do so.

   Right.  So your options are:

	1- define properties that escape the XML.
	2- use a server that preserves the prefixes.

   I assume that you do #2 today, and that the lack of a requirement  
in the spec didn't prevent that.  Yes, that means you won't like my  
DAV server because I'm not catering to your (what, to me, are  
eccentric) needs.  I do not wish to be required to do so, and I'm  
willing to lose you as a possible client as a result of my lack of  
that feature.

   I agree that if you want this to work reliably across more DAV  
servers, something has to change.  I don't think that the server spec  
is what should change; I think the property specs should change,  
which has the advantage of working in the current WebDAV framework.   
I recognize that this isn't trivial for existing services, and in  
those cases, you can keep doing #2 and use a server that fits the bill.

> >   - If we had a server that decided to implement XPath-based  
> search or
> > something similar, that server could unilaterally begin to preserve
> > prefixes as long as the standard doesn't prevent it.
>
> Alternatively, a server could unilaterally decide to not
> preserve prefixes, since the standard doesn't require it (i.e., it is
> not a MUST).

   Correct.  And twisted.web2, at present, doesn't guarantee this,  
nor does mod_dav.

> >   - If we had a client that decided to do something similar on  
> its local
> > cache/copy of data, the client would have to get a prefix-preserving
> > parser and do a bunch of other work too -- but I don't see how the
> > server behavior would entirely prevent this from working.
>
> What prevents this from working (well) is that it could do so only  
> if all
> other clients that read or wrote this property did so as well.
> This approach is likely to be a source of subtle interoperability  
> problems.

   You just told me that prefix-preserving parsers are easy to find,  
as if it was a non-issue.

   If you are storing data that required prefixes to be preserved in  
a property, of course clients that edit that data has to play nice.   
I'm not sure how even a server that guarantees the behavior you want  
can save you there.  It's going to have to preserve what the client  
sent, and if the client edits your prefixes, you're still SOL.

   On the other hand, if the data is escaped, and the client doesn't  
know that the property is escaped XML, it seems _less_ likely that if  
it did decide to write that data back out to the server that it will  
munge it before doing so.

> > So although I'm OK with saying SHOULD preserve, I see good arguments
> > for saying MAY preserve and I'm fine with that resolution too.
>
> I very rarely care about the distinction between SHOULD vs. MAY,
> and this is not one of those rare times (:-).

   Ditto.  :-)

	-wsv

Received on Friday, 23 December 2005 19:51:09 UTC