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

That works for me, unless more feedback from implementors comes up 
quite different.

Based on Julian's rewriting plus the discussion so far, here's some 
proposed wording:

The value of a property appears inside the property name element. The 
value
can be any kind of well-formed XML content: element content, text or 
mixed
content. When the property value contains element or mixed content,
namespaces that are in scope for that part of the XML document apply 
within
the property value as well, and servers MUST preserve namespaces in 
server
storage for retransmission later.  The server MAY preserve namespace 
prefixes
and non-significant whitespace.

For any values where specific prefix choices or whitespace matter (e.g. 
property
values containing XPath with prefixes), clients might need to force the 
server to
store the exact property value by encapsulating the value in a CDATA 
section.

Lisa


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