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

On Dec 23, 2005, at 1:31 AM, Julian Reschke wrote:

> So you'd be happy would be "SHOULD" be a "MAY"?

   Yes, absolutely.

   (The rest of this is banter...)

>>   Additionally:
>>     http://www.w3.org/TR/REC-xml-names/
>>   Section 3: "Note that the prefix functions only as a placeholder  
>> for a namespace name." (Note "only" is emphasized in the text...)
>
> Too bad that other W3C specs have started to use the prefix anyway,  
> and thus XML Infoset also considers it significant.

   Yeah, now that I've been forced to learn something about it, I  
hate XML.  Can you tell?  I should have challenged Tim Bray to a fist  
fight last week when I had the chance, but he's bigger than I am.

   The whole point of XML is that I shouldn't have to think about it,  
which is why I'm advocating against requirements that make me think  
really hard about it.  The serializer in PyXML decides where to park  
namespace definitions and what prefixes to use or not use.  I don't  
want to tweak the serializer, write my own, or find another library.   
If those are necessary, there's a spec problem, and in this case the  
spec problem would be in WebDAV.

   Sounds like there needs to be a serialization spec for XML as you  
suggest, then PyXML would want to conform to that, and ideally, that  
spec would address this namespace mess.  Like the ETag on PUT issue,  
I think it needs to be addressed upstream, instead of in DAV.

>>   If you define the property, senders and receivers always have to  
>> agree to honor your definition.  That's not unique here.  To me  
>> that's an argument for saying that such definitions SHOULD use  
>> #PCDATA.
>>   Geoff, I'm not following your argument that some clients might  
>> not de-serialize the data.  If you have XML there, you have  
>> structured data.  Either the client understands the property and  
>> does handles it properly or it doesn't.
>
> There are generic clients out there that display *every* property.  
> How are they supposed to know that some text indeed consists of  
> escaped XML?

   Or XML?  Or binhex goo?  I dunno, which is why generic clients are  
of limited usefulness.  They are developer tools, not user tools.

>>> Furthermore, putting escaped XML into property values *will* have  
>>> negative effects on generic clients (which will display angle  
>>> brackets to the user) and some protocol extensions (such as DASL).
>>   What's a generic client going to show the user for structured  
>> XML data that it doesn't understand?  Generic client tends to  
>> refer to a tool for l33t haxx0rz.
>
> In general, I'd expect them to only display the text content.

   The XML, you mean?  If not, what's the text content of "<foo><bar/ 
 ></foo>"?

   Only an engineer would think that a generic client is an  
acceptable UI for browsing structured data, even if it is XML "text".

   Lisa and some others in CalDAV think it's useful to have  
meaningful resource names in CalDAV because then you can browse it  
with Firefox or mount it in Finder, as if my Mom wants to crack open  
an iCalendar resource and read it for fun.  That's OK for developers,  
but it's _really_ bad UI.  Never mind localization issues and the like.

   If you are engineering for usability, generic clients aren't of  
any value.  My point being that for the audience which can actually  
use generic clients, showing angle brackets is fine.  Making  
compromises in the same of such "usability" is a mistake, I think.

   You are trading off knowing for sure, no doubt, your data won't be  
manipulated by the server for not having angle brackets in generic  
clients.  Not a great trade-off in my book.

	-wsv

Received on Friday, 23 December 2005 18:42:34 UTC