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

+1

- Jim

On Oct 5, 2005, at 5:21 PM, Geoffrey M Clemm wrote:

>
> 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
> > >
> > >
> >
> >