[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: 16 July 2001 Working Draft
/ Paul Grosso <pgrosso@arbortext.com> was heard to say:
| Do we mean to allow *any* mechanism including a hardwired internal
| list, or do we mean to require a "user-settable" mechanism? Assuming
| the latter, we might want to reword, such as:
|
| Applications conforming to this Standard must provide
| some (implementation dependent) mechanism that allows the user to establish...
| ^^^^^^^^^^^^^^^^^^^^
Done.
| In 5.1, the intro sentence includes "...identify a catalog or catalogs..."
| Delete "or catalogs" since a catalog is a list of catalog entry files,
| and it is therefore unclear what the plural of catalog would mean.
| (Then change "are" to "is" for agreement.)
Done.
| In the fourth para of this section, "the catalog(s) identified", change
| to "the catalog entry file(s) identified".
Done.
| In the fifth para, "Catalogs referenced" -> "Catalog entry files referenced".
Done.
| In the first bullet point, "processing instruction must appear in the
| prologue before the document type declaration." Change to:
| "processing instruction must appear in the prologue after the XML
| declaration and before the start of the document type declaration."
Done.
| In the third para of the first bullet point, "Applications should recover
| by ignoring catalogs" -> "Applications should recover by ignoring catalog
| entry files mentioned in such <?oasis-xml-catalog?> processing instruction".
Done.
| In the second bullet point, "each catalog specified" -> "each catalog
| entry file specified".
Done.
| In the third bullet point, "If the catalog is specified" -> "If the
| catalog entry file is specified".
Done.
| In the final bullet point, we say, "The URI that identifies the catalog
| entry file must not be subject to catalog resolution." I find the use
| of "must" ambiguous here. Wouldn't "is" be clearer than "must"? It
| is not a permission thing, it's a statement of fact: that URI is not
| subject to catalog resolution.
Fair enough.
| On the subject of delegation, we talk about "longest match". Now that
| we are doing normalization, I'm not sure "longest" is well-defined. In
| any case, I think we have to define it explicitly. Are we counting
| normalized or unnormalized characters, and what do we count when the
| URN is in the publicid URN namespace? (Yuck!)
I think we should compare normalized strings after URN "unwrapping". I
don't, in fact, think the spec supports any other semantic, but I'll
see if I can tighten it up.
If we do what I suggest, then I don't think longest is ambiguous. All
of the strings under consideration will include common characters
(either singly or %-escaped) so there can't be any question about
which is longest.
Be seeing you,
norm
--
Norman.Walsh@Sun.COM | Vision is the art of seeing things
XML Standards Engineer | invisible.--Swift
XML Technology Center |
Sun Microsystems, Inc. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC