Re: Bugzilla issue 10, was: Plan to resolve issues in 2518bis

Julian's argument was:
> Thus, we should either require 
> prefixes to be preserved, or at least state that this part of the XML 
> Infoset may not round-trip through WebDAV properties.

It appears that Lisa and Wilfredo do not like the first alternative, so
let's explore the second alternative.  I believe Julian is just saying 
here
that the specification should warn clients and servers about the negative
consequences of not round-tripping namespace prefixes (so that clients are
prepared to handle the negative consequences).  Does anyone object to this
being added?  If not, Julian, could you write up what you'd like to be 
said
here (I assume it would be something like what you say below)?  Also, one
could add guidance to a client that they escape the XML if they are 
concerned
about the non-round-tripping of namespace prefixes.

Cheers,
Geoff

Lisa wrote on 10/05/2005 06:12:52 PM:
> 
> This is a great argument for a from-scratch design, and I understand it 
> and would agree with it were we starting from a clean slate.  However, 
> we're not starting from a clean slate.
> 
>   * Existing clients have to handle servers that do prefix replacement. 
> An existing client would not benefit from more stringent rules in 
> RFC2518bis until most servers are upgraded and satisfy the new 
> requirements.  (Yes I'm aware this is a general concern with spec 
> changes but it should still factor into this trade-off calculation)
>   * Existing servers probably don't preserve prefixes, by and large. 
> Requiring so many existing implementations to change is quite a burden. 
>   For some of them this will involve performance considerations.
>   * I'm unaware of any actual interoperability problems that have arisen 

> in ordinary usage that require prefix preservation.  The template 
> example is certainly a theoretical problem I agree.
> 
> We might consider WSanchez's idea of recommending that clients create 
> self-contained XML fragments  and escape with CDATA, if the client is 
> concerned about prefix preservation.  Otherwise, unprotected XML 
> fragments are subject to server rewriting (whitespace as well as prefix 
> selection).  This seems like a more practical approach starting from 
> where we are now, and I think it handles all the cases with less spec 
> changes.
> 
> On Oct 5, 2005, at 2:47 PM, Julian Reschke wrote:
> 
> >
> > Cullen Jennings wrote:
> >> I'm not sure I understand what you mean by namespace preservation. 
> >> Take the
> >> example portion of some XML:
> >> <h:html xmlns:xdc="http://www.xml.com/books"
> >>         xmlns:h="http://www.w3.org/HTML/1998/html4">
> >>  <h:head><h:title>Book Review</h:title></h:head>
> >>  <h:body>
> >>   <xdc:bookreview>
> >>    <xdc:title>XML: A Primer</xdc:title>
> >> Is it the "http://www.xml.com/books" that gets preserved or the 
> >> "xdc". What
> >> I'm trying to ask is if would be OK if the above XML got transformed 
> >> to
> >> <h:html xmlns:foo-xdc="http://www.xml.com/books"
> >>         xmlns:h="http://www.w3.org/HTML/1998/html4">
> >>  <h:head><h:title>Book Review</h:title></h:head>
> >>  <h:body>
> >>   <foo-xdc:bookreview>
> >>    <foo-xdc:title>XML: A Primer</xdc:title>
> > >
> > > I suspect you are saying this is not OK and the namespace prefix (ie 

> > the
> > > xdc) needs to be preserved and not changed to foo-xdc. If this is 
> > what you
> > > mean, then I am not sure what you mean by this is important for XSLT 

> > and XML
> > > Schema, can you provide a bit more of an example.
> > >
> >
> > The namespace URI definitively needs to preserved, I don't think 
> > there's any question about that.
> >
> > What this issue is about is whether if it's a problem to get
> >
> >    <xyz:title xmlns:xyz="http://www.xml.com/books">XML: A 
> > Primer</xyz:title>
> >
> > or
> >
> >    <title xmlns="http://www.xml.com/books">XML: A Primer</title>
> >
> > instead.
> >
> > *Usually* that doesn't make a difference, and in a perfect world, it 
> > never would. Unfortunately, this isn't a perfect world and a long time 

> > ago, XML vocabularies have started to leak prefixes into text content 
> > and attribute values.
> >
> > Consider:
> >
> >    <xsl:template match="D:propfind" xmlns:D="DAV:">
> >
> > In this case, loosing the "D" prefix actually breaks the semantics of 
> > the document, such as in:
> >
> >    <xsl:template match="D:propfind" xmlns:ns0="DAV:">
> >
> > This is an example from XSLT/XPath, similar cases can be constructed 
> > with documents that use XML Schema, such as in
> >
> >    <count xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >    xmlns:xs="http://www.w3.org/2001/XMLSchema" 
> > xsi:type="xs:integer">123</count>
> >
> > For the record, the XML Infoset spec includes prefixes.
> >
> > So no, rewriting namespace prefixes is *not* without problems, and 
> > *will* break semantics of XML content. Thus, we should either require 
> > prefixes to be preserved, or at least state that this part of the XML 
> > Infoset may not round-trip through WebDAV properties.
> >
> >> Thanks for educating me on this - I'm not really going to end up with 

> >> much
> >> of an opinion on any of this but I am making sure I know enough to at 

> >> least
> >> understand the argument. Also, I suspect I might not be the only one 
> >> of the
> >> list that does not understand as much about XML as I wish I did :-)
> >
> > Sure :-)
> >
> > Best regards, Julian
> >
> >
> 
>