RE: FPIs to URNs

At 10:57 AM 12/5/96 EST, lee@sq.com wrote:
>> >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.  

Who is "we?" If you don't want them, don't use them. <NOTE>Names are not for
document interchange.</NOTE>. They are for document maintenance in "internal
systems", where the "systems" may be as small as a single machine, as large
as a corporation, or, eventually, as large as the Internet.

I really don't give a fig if *you* can resolve *my* FPIs. That's not why
they are there. They are there so that I can regenerate the "correct" URL in
my document as the URL changes, or so that within our organization we can
redirect to local versions, or so that documents can be cached according to
their names or ... Not so that you can "find" the documents I am pointing
at. URLS do that.

>Period.  No hand waving.  

Both 8879 and the SGML Open catalog spec allow this "hand waving." 

8879:"The system identifier can be omitted if the system can generate it
from the public identifier and/or other information available to it."

SGML Open Catalog: "This resolution does not dictate when an entity manager
should access this catalog; for example, an application may attempt other
mapping algorithms before or (if the catalog fails to produce a successful
mapping) after accessing this catalog."

Of course it is also implicit in the catalog spec that an application may
choose to implement or not to implement the catalog itself. The catalog
standard is not an SGML TC.

>No ``we left
>that out of the spec hoping no-one would notice our whole plan was
>built on a false premise' :-)

You've got it all wrong: "we left that out of the spec because we realize
that many people have many different needs and we didn't want to force a
solution." Just as XML will presumably not *require* DSSSL-O, it should not
require a particular catalog format.

Think of public identifiers as "addressing processing instructions." You
don't really expect anyone else to understand them unless you two have
"worked out a system" (like SGML catalogs or DNS based resolution). But they
are useful *without* anyone else understanding them. And if there is a good
reason to "publish" them and agree to "share them" then you have that option.

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

Ken is precisely right that SGML and XML should not, in general, standardize
behaviours. We only stray from that rule where we need to standardize a
behaviour in order to get a useful hypermedia/internet system. Since URLs
can be used to get that aforementioned useful hypermedia/internet system,
FPI resolution is never a requirement for XML document publishing or display
on the Internet. (they are VERY useful OFF of the Internet, however).

The "active/passive" rule is the basic concept underlying generic markup.
Markup is descriptive, not interpretive. Systems "use" it, not "execute" it.
In XML we are making exceptions in order to simplify the system and make
implementation straightforward. This does not have to be one of those cases
because mandatory URLs make implementation straightforward.

Furthermore, even when we specify a behaviour, for instance if we make a
defined element name a "hyperlink", or require DSSSL-O, we will not restrict
the interpretation of other elements as hyperlinks, or disallow other style
sheet formats, will we? If your system knows (somehow) that my <FOO> element
is a hyperlink (though it may not conform to the XML hyperlink description),
then it is surely allowed to attach hyperlink behaviour to it. In other
words, in every case so far, when we have attached "behaviour" to markup, we
have allowed (explicitly or implicitly) alternate mechanisms for achieving
that behaviour. The one exception that I can think of is that SOIs must be
URLs. But since the definition of "URL" is as wide as the definition of
"SOI", that is not really a restriction at all.

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

Since some FPI usages do not require automatic resolution, or *any*
resolution, reorganizing the scheme based on the idea of hierarchical
resolution is probably overly restrictive. And as David points out, what
happens if Quebec separates (for example), or Sunsoft is "spun out" of Sun?
Your hierarchy is obsolete.

I am just as resistent to forcing XML public identifiers to conform to what
we predict will be the needs of a system which is not yet in existance (URN)
as to tie it exclusively to a system that is almost certainly going to be
obsolete (for most applications) within a few years (catalogs). Technical
restrictions on URNs may require most Public Identifiers to change format in
the future. as you suggest. If we leave their resolution open, then users
can make that change in their documents in the future.

In summary: Please just leave Public Identifiers open, and the community
will choose their own solutions, just as they will for stylesheets or
meta-data formats. We could specify a "default" (as we intend to with
stylesheets), but it should not be exclusive.

 Paul Prescod

Received on Thursday, 5 December 1996 13:28:49 UTC