Re: FPI's in NOTATION declarations

There are several things that are being confused here:

[A] whether to allow PUBLIC "some string" syntax in XML;
[B] if such syntax is used, whether to make use of it;
[C] if such syntax is used, whether to retain SYSTEM identifiers;
[D] if such syntax is used, how to interpret the string;
[E] if the string is to be used and interpreted, whether to use
    the SGML OPEN CATALOG file format, or a subset of it, to convert
    the string into a sequence of data octets
[F] whether to use PUBLIC "some other string" for defining NOTATIONS;
    these strings are in SGML not used in the same way as the strings
    used for identifying entity references, and are not usually
    resolved with the SGML OPEN CATALOG mechanism.

I suggest that it doesn't matter what strings are used for [F]; they
can be FPIs if you like.  There is an SGML OPEN draft for handling
NOTATION, but it is only a draft right now.

Let's leave NOTTIONs aside for now -- they are not part of hyperlinking
(although not unrelated, like other ways of specifying link types).

I think that for [A], HTML compatibility may be a good reason to
vote Yes, but that for [B], I have still seen no compelling reasons.
The strongest has been Debbie & Paul P. wanting to be able to
change the meaning of FPIs on the client side.  This is convenient if
you have a local copy of something (URN-like), and not very SGMLish
if your copy differs from the "authoritative" copy.  In both cases, you
should really be overriding a SYSTEM identifier.

If you are referring to the Latin 1 entities and their esteemed colleagues,
though, I agree that it is convenient to have a local copy, and this
can save a not inconsiderable delay in network latency right now.

The difficulty is in having a sufficiently small set of features
to do what is needed without losing too much functionality.

So, here is my question:
    What mechanisms are proposed for including SDATA entity sets?

    I have just agreed to chair an SGML OPEN group trying to come up
    with a way of specifying the replacement text for SDATA entities;
    if that can be system independent, it may be very useful in a
    future version of XML.

    In the meantime, it is likely that you will need to have your own
    version of the Latin 1 entities, with replacement text suited for
    your local system.

    So how do you find it?

    Is it useful to be able to override other FPIs?
    Please give real, concrete examples.

If your name isn't Paul Prescod :-), you can stop reading now...

Lee



Paul Prescod <papresco@csclub.uwaterloo.ca>
> Lee wrote:
>> <!Notation TeX Public "http://www.stanford.edu/programs/TeX/2.97/">
>> and there would be no substantive difference, 
> 
> There are substantive differences. 
> 
> The first is that the first namespace is formally organized and "bigger"
> than DNS, IANA or Internic.

What does bigger mean?  I don't know how to interpret you here.
The IETF is a recognised international standards body.
The FPI namespace is no larger than dns --- they are both countably
infinite, discounting practical length limitations...
I am not sure why the size matters, though, as long as they're big enough.

> The second is that FPIs can be "redirected" by the information consumer or
> maintainer, where as URLs can only be redirected by the information
> provider.

I already pointed out that this isn't necessarily true.
Also, you are making an assumption about FPIs -- that the user can affect
their resolution.  There is nothing in ISO8879 that mandates that --
quite the reverse, if anytyhing.  I haven't checked the FPI standard,
as I don't have access to a copy right now (sorry).

> I suppose you could redirect
> URLs, but that seems like a nasty semantic mixup. If an identifier has a
> machine name in it, then the information should, at least logically, come
> from the machine (even if a cache "represents" that machine).
(1) URLs do not contain machine names except by coincidence.
    They start with Internet domain names.
(2) A URL is a coordinate in cyberspace.  To put it another way, a URL
    is indeed a resource's location, but that needn't be a resource
    that exists.

> Some people feel strongly that there should be a syntactic differentiation
> between *names* and *locations*.

Possibly.  We will have that with URNs.

> A concept cannot have a URL. It can only
> have a name, or perhaps a URN.

I think this shows that you are confused about URLs -- but we should
take that discussion offline.
It is not meaningful to say that a concept has a URL.  It is meaningful
to say that you can use a URL to represent a concept, though.
If you must have it point at something, point at a textual description.

> I think that the first time you "click" on a
> "concept:" you'll wish that they were distinct also.
I was referring to URNs, not the HREF attribute of an HTML <A> element.
You are going to have a hard time dereferencing your TeX Book example
FPI too, if you "click on it".

Obviously that isn't what it is for.

> Anyhow, a major benefit of having URLs *and* FPIs is redundancy. I think
> that they should usually be used together.

We don't need redundant syntax.  We need a minimal language that people
actually implement.

> >[3] client-side indirection
> 
[...]

> Isn't that what SGML Open is for?

You mean the CATALOG TR, I assume, rather than the organisation?

> The problem FPIs partially solve
> is *hard*. FPIs provide a partial solution that URLs do not.

No.  FPIs plus the SGML OPEN catalog plus URLs provide a partial solution.
FPIs by themselves are nothing but structured strings, just like URLs,
URNs, telephone numbers and those knotted Mayan things :-)

> >    There is no reason why a client-side URL lookaside table could not be
> >    used to give this functionality with URLs.
> 
> As I stated before, I think that this is attempting to make URLs into
> something they are not. I don't really feel comfortable having clients
> redirect URL accesses.  With a separate syntax it is clear from the document
> that a redirection is possible, if your tool supports it.

But then every XML program needs to support the SGML OPEN catalog,
and we have to work out how to associate an SGML OPEN catalog with
every XML file, and how to do that in the presence of CGI, and how
to store multuple XML document sets in the same directory without
CATALOG conflict, and document it all, and still be under 20pp.

I am not opposed to solving the problems that need to be solved, but only
to confusing functionality and requirements with mechanism.
If this is what we need to do, we'll do it.

Lee

Received on Thursday, 28 November 1996 23:40:39 UTC