Re: Fried Parrot Intestines in my XML Soup

At 3:53 PM 12/2/96, 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)
  Correction: use URN resolution in conjunction with the URN FPI
grandfathering rules.
   Now objection 1 is moot.
>(2) you can use URNs in the SYSTEM identifiers if you like

I don't think that this is true -- if it is true, we've got at least a
start on something resonable: we just need to get the URN people moving on
a namespace ID for FPIs, and we can use FPIs. However, and this is pretty
important: we lose tha bility to have an FPI _and_ a URL. So by insisting
on inappropriate resolution stategies, we make FPIs harder to use for those
already using them, and more likely to break the software of those not
using them.

  Seems like a lose-lose proposition, unless we allow multiple URIs in the
SYSTEM id.


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

There's a lot more than emotional attachment, but unfortunately some people
just have a glitch about names: they don't understand resolution-protocol
independent resolution. Looking something up in a book or writing a letter
are _valid_, _useful_, perhaps even _necessary_ resolution methods, just as
is the use of some TCP/IP protocol.

>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.  The CATALOG mechanism
>only helps you tie together an FPI and some data once you have already used
>some other mechanism to fetch the data -- e.g. typed it in probably mostly OK
>from the SGML Handbook or the Annex or the JoanSmithPinkThing.
FPIs do always get you the same data, if they are used correctly. That's
the definition of them, and the contract, that you commit to when you
assign an FPI.

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

As you say. This is the point -- the resolution method you use in unique,
but that's OK, because a name is a name is a name is a name.

>If so,  we need to consider a mechanism to do that in XML.
>It could be with FPIs.  It could be with URNs.  It could be something
>entirely different.  First we have to understand what we are trying to
>achieve,and only then consider how to do it.

No, we can consider whether FPIs, which are good on their own merits,
support this mechanism. And, surprise! -- they do.

>Other people use FPIs as a kind of indirection, so that filenames are
>not wired in, e.g. in case the installation in <VOL4>EUROPE>SGML>SW.DIR;3
>(Is that a valid PR1MOS networth path?) is moved.

This is one perfectly valid way to use FPIs.

>This is a different purpose, and although the same mechanism might solve
>both needs, it might also be appropriate to use two mechanisms.
>It's done in C, for example, with a file inclusion path:
>#include <stdio.h>
>looks in a per-installation standard place (or places) for the file
>"stdio.h"; you can add more directories to the list, e.g. with -I on
>most C compilers, or in a dialogue box for preferences on some systems.
>#include "stdio.h"
>looks (by default) in the same place as the file containing that line,
>like a relative/partial URL.
>I am not here proposing C's semantics (or syntax!) for XML, but only
>pointing out that there are other mechanisms.

FPIs are a social discipline for naming, independent of mechanisms. Your
"c" syntax is also an acceptable mechanism for FPIs. FPIS are _NOT_ about
mechanism.

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

Persistent, globally-unique, resolution mechanism-independent identifiers
for internet resources, for use in XML documents.

>For those of you who think it's a fought-and-won battle, I can only say
>that there mere fact that everyone didn't immediately say yes indicates
>that this isn't so.

It shows that some people don't understand the difference between names and
locations, nothing more. Read the URN group logs. There is no solution to
this argument, either you agree to let the "namers" have their "harmless
games" or they lose capabilities that they depend on and you don't believe
in. I'm sorry, but there's not much more to it, once we have agreed to
forswear philosophy.

>
>Hence, I suggest that we need the following:
>* a list of required functionality
Persistent, globally-unique, resolution mechanism-independent identifiers
for internet resources, for use in XML documents.

>* discussion of possible approaches to providing that functionality
A way to assign strings to resources that will not be reused to identify
other resources, in the next 500 years (assuming the continuance of people
who care about such things).

>* final choice of mechanism(s)
Why not FPIs? they meet the reqwuirements, and are already part of SGML
(and soon to be part of the URN facilities)

>* discussion on syntax, if needed

hierarchical authority-based name assignment (like FPIs) is the easiest
name-assignment discipline to implement.

>* final shoice of syntax

Why not FPIs, they already exist, and are compatible, etc.??

   -- David, who cannot believe he is having this same discussion again.


I am not a number. I am an undefined character.
_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________

Received on Monday, 2 December 1996 16:28:51 UTC