OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

entity-resolution message

[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