Section 5.2 of draft-ietf-webdav-rfc2518bis-13 still has problems

The editing changes made to the proposed text for this section introduced 
a variety of problems:
OLD>> When a WebDAV resource has a URL U, such that U is the same as URL V 
plus a single additional path segment, then if the resource identified by 
V is WebDAV compliant it MUST be a collection that has U as an internal 
member URL. For example, if "http://example.com/bar/blah" is a WebDAV 
resource, then if "http://example.com/bar/" is WebDAV compliant, it MUST 
be a collection and MUST contain "http://example.com/bar/blah" as an 
internal member.
PROBLEM>> This talks about "U having an internal member URL".  U does not 
have an internal member URL ... it has a mapping from a segment name to an 
internal member resource.  That internal member resource has a URL, but 
*U* does not have that internal member URL.  Also, the use of "it" in the 
last sentence is ambiguous, since two different resources have been 
identified in the sentence.  Please adopt the original proposed text to 
solve these problems, i.e.:
NEW>> For all WebDAV compliant resources A and B, identified by URLs "U" 
and "V" respectively, such that "V" is equal to "U/SEGMENT", A MUST be a 
collection that contains a mapping from "SEGMENT" to B. So, if resource B 
with URL "http://example.com/bar/blah" is WebDAV compliant and if resource 
A with URL "http://example.com/bar/" is WebDAV compliant, then resource A 
must be a collection and must contain a mapping from "blah" to B. 

OLD>> Collection resources MAY have internal members with mappings to 
non-WebDAV compliant children in the HTTP URL namespace hierarchy but are 
not required to do so. For example, if the resource X with URL 
"http://example.com/bar/index.html" is not WebDAV compliant and the 
resource with URL "http://example.com/bar/" identifies a collection, then 
collection "bar" might or might not have an internal member with a mapping 
from "index.html" to the resource X. 
PROBLEM>> An internal member is the child resource ... the internal member 
does not have the mappings (the collection has the mappings).  Also 
calling the collection "bar" is misleading ... "bar" is just a URI segment 
that is currently bound to the collection in the "http://example.com/" 
collection.  Please adopt the original proposed text to solve these 
problems, i.e.:
NEW>> Collection resources MAY have mappings to non-WebDAV compliant 
resources in the HTTP URL namespace hierarchy but are not required to do 
so. For example, if the resource X with URL "http://example.com/bar/blah" 
is not WebDAV compliant and the resource A with "URL 
http://example.com/bar/" identifies a collection, then A may or may not 
have a mapping from "blah" to X. 
Cheers,
Geoff