[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