Public Identifiers

[Toby Speight]

Steven> Steven R. Newcomb <URL:mailto:srn at techno.com>

0> In article <199809211142.GAA00670 at bruno.techno.com>, Steven wrote:

Steven> The problems with the quotation from RFC 1737 are these:
Steven>
Steven> * Who defines what constitutes a name assignment authority?
Steven>   If it's the end user, in an ad hoc fashion, that's fine, I'm
Steven>   satisfied.  But the language of the RFC,

When a URN scheme (namespace) is registered at IANA, one of the data
required for registration is how names are assigned.  In the case of
FPIs, the registration document would simply refer to the assignment
rules in the FPI definition.  (I don't believe that an FPI URN scheme
has yet been proposed - and if it is, I expect that it won't include
all possible FPIs, since IDN FPIs are not necessarily persistent).


Steven> [quote RFC 1737:]

#> For example, ISBN numbers, ISO public identifiers, and UPC product
#> codes seem to satisfy the functional requirements, and allow an
#> embedding that satisfies the syntactic requirements described here.

Steven>   ...indicates otherwise.  Here, in all three examples, there
Steven>   is a name registration authority; the end user is evidently
Steven>   not allowed to specify the Sears 1922 Farm Catalog unless
Steven>   this has already become a formally-cataloged public entity
Steven>   of some kind.

Just the same as for FPIs, yes?


Steven>   (Note that it's not clear whether "ISO public identifiers" means
Steven>   "public identifiers in ISO syntax" or "public identifiers that
Steven>   begin with the letters 'ISO' and that define public text entities
Steven>   that were created under the auspices of the ISO".  There is a
Steven>   very small set of the latter -- a set that has little or nothing
Steven>   to do with what I'm concerned about here.)

Agreed.


Steven> * There is an even more problematic statement: "A URL identifies
Steven>   the location or a container for an instance of a resource
Steven>   identified by a URN."  This strongly implies that there must
Steven>   be a URL behind every URN, even if that URL is fictitious or
Steven>   doesn't happen to work.

I'm not sure that I see that implication - to me it explains the
meaning of having an URL for a given URN.  AFAICT from reading RFC
1737 and the URN mailing list, resolution of a URN may result in zero
or more URLs.


Steven> The fact that you make such a point of demonstrating the
Steven> conversion of my FPI into a URN makes me wonder whether you
Steven> understood my question.  In the scenario I'm asking about,
Steven> there is never any need to transmit the FPI, so there's no
Steven> need to convert it.

Storing it into a document (as a URI) counts as transmission in my
book.  If you want to represent an FPI in a XML system identifier, you
need to use the URN syntax, since the XML spec says that system IDs
must be URIs.  Similarly for any other use of an FPI in a context
where a URI is expected.

-- 


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)