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: NID request for publicid (draft-urn-publicid-03.txt)


Editorial corrections to what Norman Walsh wrote:


>    In addition to the character set restriction, public identifiers
>    must be normalized by removing all leading and trailing whitespace
>    (the characters #x20, #xD, and #xA, in this context) and replacing
>    all remaining sequences of two or more whitespace characters with a
>    single space (#x20).

Oopsie, this isn't quite what XML 1.0 says: it would leave a single
CR, LF, or TAB alone rather than changing it to a SPACE.

I suggest replacing this sentence with something very close to the
XML 1.0 wording:

#    In addition to the character set restriction, public identifiers
#    must be normalized by changing all strings of whitespace
#    (the characters #x20, #xD, and #xA, in this context) to single
#    space characters (#x20), and removing all leading and trailing
#    whitespace.

>    FPIs are strings composed from the same range of characters as
>    public identifiers, but with an explicit internal structure.  The
>    structure of Formal Public Identifiers is normatively described in
>    SGML[3], we review it here for convenience. 

Change this comma to a semicolon.
 
>    Owner identifiers may begin with "-//" or "+//", otherwise "//" is
>    used to delimit fields in the FPI (with the exception of the public
>    text class which is delimited from the public text description by a
>    space).

And this one too.

>          Registration Date: 2001-04-19

Update this date?
 
>           The rules for "+", ":", "/", and ";" are required to preserve
>             the special significance of literal occurrences of these
>             characters in the 'publicid' URN namespace. 

Drop "the special significance of".
 
>           The remaining characters, "'", "?", "#", and "%", are the
>             only other legal characters in public identifiers that
>             cannot be literally transcribed into a URN by the rules of
>             RFC 2141[5] and RFC 2396[6]. 

Add SPACE to this list.
 
>          There is no requirement that a resource may have only one
>          public identifier.

Omit "may".

>          Identifiers in the "publicid" namespace may be resolved by the
>          same policies and procedures as public identifiers. Public
>          identifiers can be resolved in many different ways. Most
>          existing systems provide facilities for resolving them by way
>          of OASIS TR9401[8] Catalog files. Other systems resolve them
>          by mapping each component to a local pathname component. And
>          some systems simply "know about" a fixed set of public
>          identifiers. In addition, URNs in the 'publicid' namespace may
>          be resolvable by other mechanisms unique to URIs (such as
>          caches).

For "Most existing systems" read "Many existing systems".

>    Conformance with URN Syntax: 
> 
>          No special considerations.

State here that we comply with both RFC 2141 and RFC 2396.
-- 
There is / one art             || John Cowan <jcowan@reutershealth.com>
no more / no less              || http://www.reutershealth.com
to do / all things             || http://www.ccil.org/~cowan
with art- / lessness           \\ -- Piet Hein



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC