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)


/ John Cowan <jcowan@reutershealth.com> was heard to say:
| 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.

Done.

| >    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.

Ok.

| >    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.

Yep.

| >          Registration Date: 2001-04-19
| 
| Update this date?

Done. I'm not sure if this is supposed to change when the document
goes to RFC or not. Presumably the appropriate IETF editor will do so,
if appropriate.

| >           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".

Ok.

| >           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.

Ok.

| >          There is no requirement that a resource may have only one
| >          public identifier.
| 
| Omit "may".

Done.

| >          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
[...]
| 
| For "Most existing systems" read "Many existing systems".

Ok.

| >    Conformance with URN Syntax:          No special considerations.
| 
| State here that we comply with both RFC 2141 and RFC 2396.

Check.

New draft momentarily.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | One's never alone with a rubber duck.
http://nwalsh.com/            | 


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


Powered by eList eXpress LLC