RE: FPIs to URNs

I had written that I could use
> ><!DOCTYPE Baileys PUBLIC "urn:urn.mitra.org//Liam
> >Quin//bailey.dtd;version=3.4">
> >just as happily.
> >
> >Note that this meets Debbie's requirement without actually being an
> >SGML Formal Public Identifier.  I.e., there are other possible
> >solutions.

Ken Holman was confused by my example -- which wasn't clear to those who
have not followed URNs at all, I agree.  Sorry.  He said:

> I don't think this meets my requirement because of the implication of
> location in the URN.

There is no implication of location in the URN.  That's why it's a URN.
The "urn.mitra.org" mentioned here is not a host, and is not contacted,
and is not the location of the resource.

It's a URN.

N.

not L.

If it is easier to understand, imagine, if you will, that I am asking
for a slightly different syntax for FPIs, with a hierarchy of organisations
who can allocate naming authority prefixes.
	+//NA:US:CA:SUN:SUNSOFT:DIVDOC//DTD XXX YYY//EN
for example.

This would be easier to arrange for automatic resolution, easier
to administer and more robust.  Or so it seems to me.


> >For example, using PUBLIC "urn:urn.mitra.org//Liam
> Quin//bailey.dtd;version=3.4":  How would I override an XML processor
> from accessing "urn.mitra.org" to give me the entity when I would rather
> use a local file?

Ignoring the misunderstanding about the domain name....
This is a real issue.  A lookaside cache can be called CATALOG if it
makes people happy, but that is all it is; you can have a cache for anything.

> I want to override this without having to get into the
> file with my clumsy fingers and risk "breaking" something while I'm in
> the file.

So you need a tool.

[...]

> >This is my biggest concern with the (literally) millions of
> >unregistered
> >public identifiers belonging to tens of thousands or hundreds of
> >thousands or more of issuing "authorities".
> 
> Good reasons for me to not include the resolution aspects of any kind of
> identifier in the XML specification.

If we don't believe they will work, WE MUST NOT RELY ON THEM, and
cannot use them in the spec.  Period.  No hand waving.  No ``we left
that out of the spec hoping no-one would notice our whole plan was
built on a false premise' :-)

> We are defining a meta-language
> for document markup that identifies information in a file.  I've always
> viewed SGML (and XML) as passive, not active.

I don't follow this -- we are discussing the underpinnings of a
hyperlinking mechanism.  Whether you believe hyperlinking to be
grammatically male or female, active or passive, it still has to be
specified.  XML is not the same as SGML.  This sounds supiciously like
Conformance to Folklore to me.  Where in ISO 8879 are these active/passive
terms defined?  Where does this rule come from"

> >Really, an SGML OPEN catalog could be thought of as a local entity
> >cache;
> >although they are often mantained by hand today, if URN resolution were
> >used, a catalog could point into one's URN cache automatically...
> 
> Great flexibility!  Just think, I didn't have to change my markup to
> point into my URN cache.

I am not sure if this is cynicism or genuine (sorry).

> >But in that case, perhaps it wouldn't be needed any more.
> 
> But it would be needed, because the next day I may not want my catalog
> to point into my URN cache (or anybody else's URN cache, or somebody
> else pointing into my URN cache (I might be sensitive about that!:{)).

I _really_ don't understand that.  If you dont want to use the copy
of an FPI's text that's in your CATALOG, you know what to do about
it.  All I did was change the names, not the mechanism: it's still
an SGML OPEN CATALOG.

> >So, is there a URN scheme that scales in a way that makes it easier
> >to implement than grandfathering SGML FPIs?
> 
> In my opinion, these are solving two different problems, hence, no URN
> scheme would successfully grandfather FPI's.
> 
> I want my FPI's to be absolutely permanent if I wish, so my sacrosanct
> document remains inviolable, yet I have the flexibility to work with
> that document in any environment I have now, or have to work in in the
> future.

You can't have that.  You will already have to change your environment
to work with XML.

If FPIs are "grandfathered" as has been discussed, they become URNs.
Every FPI is then automatically and henceforward a URN.

So there is no point in saying that you want FPIs and not URNs,
because you can't have that.

If it is easier to understand, imagine, if you will, that I am asking
for a slightly different syntax for FPIs, with a hierarchy of organisations
who can allocate naming authority prefixes.
	+//NA:US:CA:SUN:SUNSOFT//DTD XXX//EN
for example.

This would be easier to arrange for automatic resolution, easier
to administer and more robust.  Or so it seems to me.

Lee

Received on Thursday, 5 December 1996 10:57:21 UTC