Remy said:
> Actually, I had the same exact modification you describe done a few weeks
ago, but that's when my HD died :-(
Ouch. Hearing you say that makes me want to back up my system right now.
:)
> Then another solution was proposed, and appeared to be working fine, so I
didn't bother writing that code again.
I see. I'm hoping that in addition to solving the name/namespace problem we
can support multiple namespace aliases, e.g. requests like:
<D:propfind xmlns:D="DAV:">
<D:prop xmlns:e="urn:schemas:httpmail:"
xmlns:i="urn:schemas:mailheader:"
xmlns:f="http://schemas.microsoft.com/exchange/";
>
<e:hasattachment/>
<i:subject/>
<f:permanenturl/>
<f:defaultrevision/>
</D:prop>
</D:propfind>
Obviously, the tricky part is when two or more elements share the same
namespace alias (as in alias "f" above). If I'm reading it correctly, I
believe the current code repeats those namespaces for every element, reusing
the same alias ("ZZ"). That's legal and certainly okay, but if adopting
this Property object scheme means we get multiple namespace aliases for
free, I think that's pretty cool.
Shawn
-----Original Message-----
From: Remy Maucherat [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 02, 2001 1:24 PM
To: [EMAIL PROTECTED]
Subject: Re: xml names, webdav namespaces, and isUnicodeIdentifierPart()
> Hey Michael,
>
> I've been looking at that code recently. The company I work for is using
> the Slide client library to talk to Microsoft Exchange 2000 (mostly for
> address book and calendar functionality). The code you refer to below has
> been causing us some consternation, in that it doesn't seem to properly
> handle multiple namespaces in the same request - besides the fact that it
> doesn't properly separate name from namespace in all circumstances. I'd
> like to propose a solution to both problems at once.
>
> Determining what characters are or aren't legal in element names isn't the
> job of Slide - it's the job of an XML parser, and I think we should let a
> parser do that job. I propose that we augment your solution, below, with
a
> simple change. Instead of accepting an enumeration of strings
representing
> the element's namespace/name pair, the propfind could optionally accept an
> enumeration of objects each representing a property.
Actually, I had the same exact modification you describe done a few weeks
ago, but that's when my HD died :-(
I was checking the type of the object in the enumeration, and if it was a
Property, I was using that to retrieve the namespace URI and the local name.
Then another solution was proposed, and appeared to be working fine, so I
didn't bother writing that code again.
> If, for the sake of argument, propfind checked the type of the objects in
> the enumeration it's passed, it could handle Property objects specially.
> The org.apache.webdav.lib.Property interface, as you know, contains
separate
> fields for namespace, name, and local name, so using Property obviates the
> need to do the parsing in the Slide library. The old-style enumeration of
> strings would still be supported for backwards compatibility.
>
> This solution wouldn't require a change in PropFindMethod's public
> interface.
>
> I'm totally open to other solutions as well. I just wanted to get the
ball
> rolling...
Remy
