Re: New draft published

[Norman Walsh <ndw@nwalsh.com>]

/ Paul Grosso <pgrosso@arbortext.com> was heard to say:
| Why does it sometimes say "Table of Contents" in the middle of nowhere in
| odd places?  The one after 4.1 is particularly confusing because it then
| says 4.1.1 Prefer attribute but it's really not section 4.1.1, it's section
| 4.1 about external identifiers (and the ref to 4.1.1 is the one line toc
| referring to the upcoming section 4.1.1--very confusing).

Stylesheet bug.

| In 6.2 we refer ti "white space" without defining it.  You should make
| that a link to the defn of white space in XML 1.0 which is production 3:
| http://www.w3.org/TR/REC-xml#NT-S

Ok.

| In 6.3, you say that "catalog processors must perform normalization on URI 
| reference in both the catalog and the input passed to them."  First,
| "URI reference" -> "URI references".  Next, I think that's wrong as far
| as "URI reference in...the catalog".  Since you are talking about matching,
| you must be talking about the lhs, but neither the system nor the URI
| entry type has a URI reference on the lhs.  Per 6.5.4 and 6.5.8, both 
| lhs's are things of type "string".  The rhs of both is of type URI ref,
| but it doesn't make sense to talk of normalizing it.  So this para seems
| to need rewording.

I agree that they aren't defined as URI references, but that doesn't
mean we couldn't mandate performing the character-level URI
normalization on them.  Are you suggesting we shouldn't? If so, then
there will be strings that you can put on the LHS that will never,
ever match. That seems silly. If the idempotent normalization can be
done on the input string, why not on the catalog string?

| In 6.5.3, I see "The URI reference should not include a fragment identifier."
| I think I keep objecting to this, and maybe I keep getting an answer why I'm
| wrong, but I have to be reminded one more time, I guess.  Why this restriction?

The purpose of the public entry is to return a URI for use by the XML
parser in retrieving a resource. It maps a public identifier to a system
identifer. XML 1.02e forbids fragment identifiers on system identifiers.
So if you put a fragid on the RHS of a public entry, you're bound to return
an invalid system identifier.

| In 6.5.4 and 6.5.5 it talks about matching the normalized value of a sysid.
| Again, I think I'm forgetting something, but this still doesn't make sense
| to me, esp. since the bit in 6.3 about normalizing made no sense to me.  Why

The 6.3 bit is taken right from the XML Erratum 78 which I know you've
suggested should be undone in PE71. Mumble. We did talk about this at
one or more telcons.

I see now that even XML 1.0 (from 1998) had some text in S4.2.2
dealing with non-ASCII characters being %-escaped.

The point (or a point, anyway) about the normalization in 6.3 is that it
is idempotent. It can't hurt.

Given "some{thing}", it will return "some%7Bthing%7D".
Given "some%7Bthing%7D", it will return "some%7Bthing%7D".

So if the LHS and the input string are always normalized in this way,
then non-ASCII characaters (and reserved ASCII characters) will always
compare properly.

                                        Be seeing you,
                                          norm

-- 
Norman.Walsh@Sun.COM   | If someone tells you he is going to make 'a
XML Standards Engineer | realistic decision', you immediately
Technology Dev. Group  | understand that he has resolved to do
Sun Microsystems, Inc. | something bad.--Mary McCarthy