W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

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

From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Fri, 23 Dec 2005 11:15:28 -0500
To: " webdav" <w3c-dist-auth@w3.org>
Message-ID: <OFE2AE4746.47A3D4C1-ON852570E0.00572792-852570E0.00594EE1@us.ibm.com>
Lisa wrote on 12/23/2005 10:48:14 AM:

> Let's say that
>    1.  client X wants to use prefixes and store XML schema and XSLT data 

> in property values.
>    2.  client Y expects that value to be in ordinary XML, not 
> encapsulated.
>    3.  server S does not preserve prefixes.
> I'm trying to understand here, how does the behavior of Y and S prevent 
> X from doing what it wants to do?  Can't client X still store that 
> information or at least reconstruct it, if it wants to use prefixes in 
> local computations?  It might be messy, but it ought to be possible to 
> preserve the original mappings somewhere the server won't mess with it 
> (e.g. add an attribute 'originalmapping:x="http://example.com/ns"'). 
> Knowing how existing servers tend not to preserve prefixes anyway, I'd 
> imagine this is what client X would have to do regardless, in order to 
> work.

There might be something that client X could do, but the proposal we
were discussing was simply escaping the XML as a string via #PCDATA.
That proposal would cause client Y to break.

We could discuss an alternative proposal such as the one you describe
above, but a user of client Y would still get back broken XSLT or
broken XML-schema data, because client Y doesn't know how to use the 
originalmapping information to fix it up.  Also, this approach is
likely to be a lot of work for the client, so it isn't a "simple"
approach(which was what the #PCDATA approach was trying to achieve).

So I have not yet heard a "good" alternative to solving this problem
other than recommending that servers preserve namespace mappings.

Received on Friday, 23 December 2005 16:16:05 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:34 UTC