Re: Fried Parrot Intestines in my XML Soup

At 03:53 PM 12/2/96 EST, lee@sq.com wrote:
>> If the defined method of resolution is "resolve as URNs", which
>> various systems may do variously but with the same results (unless
>> some succeed and some fail), does that suffice for you? 
>
>For me it doesn't, because
>(1) an FPI isn't (last time a checked) a full valid URN (e.g. lacks the
>    urn: prefix)

This isn't a problem. Just prepend urn:fpi: to the front. We may want to
consider how we are going to address *full* urn:'s in the future, though. We
should reserve an urn: prefix in the PublicID syntax now.

>(2) you can use URNs in the SYSTEM identifiers if you like.

We've discussed the downside of this already. 
 * First, the spec. doesn't allow it. 
 * Second, if we change "URL" to "URI" then we have no transition mechanism.
We must wait until our readers all have name-enabled browsers to use them
*at all*.
 * Third, all of our name-enabled SGML tools break, for no good reason.

>There is obviously a lot of emotional attachment to formal public identifiers.

No. There is a lot of technical attachment to names, and FPIs are a naming
mechanism that work, that we can continue to use with only a small change to
the standard. We are just asking you not to break our working systems
because you haven't personally found a need for a feature.

>In some cases perhaps it's because people think that resolving an FPI always
>gets you the same data,  It doesn't.  There isn't even a resolution mechanism
>defined apart from Write a letter to ISO or the GCA.  

**WHO CARES?** There isn't a well defined resolution mechanism for "Lee
Quin" but I find it useful to refer to you anyways. Only I want is the
*right* to name things in addition to pointing to them.

>It is true that a way to refer to commonly available files (DTDs, entity sets,
>the SunSoft logo :-), notation definitions perhaps) in a way that would
>allow a lookaside cache is useful.  We include a number of common entity sets
>and DTDs with SoftQuad Panorama, so that if you put something on the web
>with one of those DTDs, the user doesn't need to download it... and the
>software knows that.
>
>That's useful for SGML and Panorama.
>Would it be useful for XML?

Why not? Have we come to the end of DTDs? or entity sets?

>We have focussed in very closely on FPIs, but I don't think we've
>talked enough about what problems we are trying to solve.

As David said: "Persistent, globally-unique, resolution
mechanism-independent identifiers for internet resources, for use in XML
documents."

Okay. I have 10 000 students around the world. We all have the same DTD. We
all have a common set of entities defined. We may be using common XML
software, we may not be. I need a way to send them XML documents that refer
to those DTDs and entities in a way that is not dependant on the network,
because they will use it off of the network. FPIs solve this problem. URLs
*cannot*, because I cannot know where on their machine their DTDs and
entities are. I also cannot require them to edit a text file (either a
catalog file or a .sgm) to fix it.

This is a real problem I have (100 students, not 10 000).

Let's say, instead, that we are on an Intranet. FPIs are stored in a
relational database and translated to URLs by the database. URLs cannot
work, because they are not names, and are bound to particular network
protocols. 

>Hence, I suggest that we need the following:
>* a list of required functionality

David has provided that. "Persistent, globally-unique, resolution
mechanism-independent identifiers for internet resources, for use in XML
documents."

>* discussion of possible approaches to providing that functionality

I think we've already discussed three: "URL or URN, pick one", "as many URLs
or URNs as you want" and "FPIs and URLs".

URLs are not persistent, or resolution mechanism independent.

 Paul Prescod

Received on Monday, 2 December 1996 17:43:01 UTC