xml names, webdav namespaces, and isUnicodeIdentifierPart()

[Michael Smith <ms...@speedlegal.com>]

Hi all,

I just committed a little workaround for a problem (using the client
libraries) doing a propfind on any property with '-' in the property
name (current-user-privelege-set, specifically).

The library was doing this: to split a string between namespace
abbreviation and name, when looking at the element name, it went
backwards from the end, checking each character to see if it was a valid
part of an xml name. If it gets to the start, there's no namespace. If
it doesn't, then it can split into namespace and name. This is fine, but
the check for 'valid part of xml name' appeared broken. 

It was calling Character.isUnicodeIdentifierPart(chr). The javadoc is
somewhat evasive on what _exactly_ this does (I assume it's fairly well
defined by the unicode standard, but I couldn't find the right
information in a look around unicode.org, and I don't have a copy of the
unicode book). The XML spec is explicit about exactly which codepoints
are allowed. Specifically, as well as several standard unicode character
classes (letters, digits, etc.), it gives '-', '.', and '_' as allowed.
isUnicodeIdentifierPart() rejects '-' (the javadoc says that _ is
allowed. I think (though I didn't test this explicitly) that '.' is also
allowed). 

For now, I've changed this check to isUnicodeIdentifierPart(chr) ||
chr=='-'. This works, but seems terribly inelegent. I also suspect that
isUnicodeIdentifierPart() lets through some things that it shouldn't,
though I haven't checked into this properly.

Are there any unicode and/or xml experts on the list who could weigh in
with an opinion on what the correct check is, here? It's a minor detail,
really, but it's the sort of minor detail that has a tendency to bite
you later if you don't get it right the first time.

Michael

RE: xml names, webdav namespaces, and isUnicodeIdentifierPart()

["Shawn C. Dodd" <sd...@agea.com>]

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:remm@apache.org]
Sent: Thursday, August 02, 2001 1:24 PM
To: slide-dev@jakarta.apache.org
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

Re: xml names, webdav namespaces, and isUnicodeIdentifierPart()

[Remy Maucherat <re...@apache.org>]

> 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

RE: xml names, webdav namespaces, and isUnicodeIdentifierPart()

["Shawn C. Dodd" <sd...@agea.com>]

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.

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


Shawn

-----Original Message-----
From: msmith [mailto:msmith]On Behalf Of Michael Smith
Sent: Tuesday, July 31, 2001 9:25 PM
To: slide-dev@jakarta.apache.org
Subject: xml names, webdav namespaces, and isUnicodeIdentifierPart()

Hi all,

I just committed a little workaround for a problem (using the client
libraries) doing a propfind on any property with '-' in the property
name (current-user-privelege-set, specifically).

The library was doing this: to split a string between namespace
abbreviation and name, when looking at the element name, it went
backwards from the end, checking each character to see if it was a valid
part of an xml name. If it gets to the start, there's no namespace. If
it doesn't, then it can split into namespace and name. This is fine, but
the check for 'valid part of xml name' appeared broken.

It was calling Character.isUnicodeIdentifierPart(chr). The javadoc is
somewhat evasive on what _exactly_ this does (I assume it's fairly well
defined by the unicode standard, but I couldn't find the right
information in a look around unicode.org, and I don't have a copy of the
unicode book). The XML spec is explicit about exactly which codepoints
are allowed. Specifically, as well as several standard unicode character
classes (letters, digits, etc.), it gives '-', '.', and '_' as allowed.
isUnicodeIdentifierPart() rejects '-' (the javadoc says that _ is
allowed. I think (though I didn't test this explicitly) that '.' is also
allowed).

For now, I've changed this check to isUnicodeIdentifierPart(chr) ||
chr=='-'. This works, but seems terribly inelegent. I also suspect that
isUnicodeIdentifierPart() lets through some things that it shouldn't,
though I haven't checked into this properly.

Are there any unicode and/or xml experts on the list who could weigh in
with an opinion on what the correct check is, here? It's a minor detail,
really, but it's the sort of minor detail that has a tendency to bite
you later if you don't get it right the first time.

Michael