Ron Daniel <[log in to unmask]> wrote:
>On Jan 1, 2:29pm, Keith M. Corbett wrote:
>> Ron, at 12:51 PM 12/21/95 EST you wrote:
>> >[...] FPIs are one naming system that I would like to
>> >see handled as URNs. According to our current compromise,
>> >such a thing might look like
>> > "urn:FPI:-//IETF//DTD HTML 2.0//EN"
>> >so references to them would most likely look like
>> > <!doctype HTML system "urn:FPI:-//IETF//DTD HTML 2.0//EN">
>> Looking back at this message it struck me, perhaps you favor using system
>> identifiers directly to work URNs into document type declarations...? Or
>> maybe this was just a "quick and dirty" example?
>I *would* like to be able to use URIs as system identifiers, but the example
>above using FPIs is somewhat unfortunate. James Thurber showed me the
>error of my ways when he suggested that we leave FPIs as FPIs and
>let a smart entity manager translate them to URIs and try to resolve them
>over the net if they didn't already know what the thing was. His approach
>has the nice property of not breaking a few hundred million
>People who want to use some name other than an FPI could still use
>a URI in a system identifier, but for FPIs I now think it is best to
>leave them as PUBLIC identifiers.
Not to sound like I'm slamming you Ron, but this was precisely my protest
in using embedded locations in DOCTYPE. The purpose of DOCTYPE is to
declare a DTD, not the location of the DTD. Embedding the location,
especially one as transient as a URL, in a document seems to ignore the
existence of public identifiers. If one were operating entirely locally,
this would make some sense, but not over the Web.
>> There are practical advantages to using FPIs to declare external entities,
>> including DTDs. Burying the FPI within a system identifier seems like a
>> step backward.
If it _needed_ seconding, I agree as well. Now if we can just get some
combination of URIs, catalog files, and content negotiation working, we'll
have an operable system... hmmmmm.
I've been sitting on a wild hair this morning trying to think how some sort
of parameter-passing mechanism might switch in and out marked sections of a
DTD based on some variable internal or external to DOCTYPE (something in
HEAD?), to allow for the document to specify exactly what features it needs
of the various (extended-) system components. This would allow one core DTD
to fulfill varying requirements. Like I said, a wild hair.
Murray M. Altheim, Information Systems Analyst
National Technology Transfer Center, Wheeling, West Virginia
email: [log in to unmask]