Re: Can we be more concrete?

At 12:08 PM 12/30/96 -0600, len bullard wrote:

>> In the HyTime model, these would be location addresses, not links.  
>
>yes.  Pixel addresses are absolute locations in concrete documents.

What I meant was that *however* you did the addressing, it would be a
location address and never a link (using the strict distinction between
linking and addresing that HyTime makes).

>> I'm not
>> sure I understand the point of your comment: I thought my proposal was
>> sufficient (not that I was trying to propose a useful scheme for doing
>> image addressing--it was just a quick example).
>
>It is.  I wanted to point out what was missing.  As soon as pixel 
>coordinates are separated from content, the origin is needed for 
>complete independence, or the maintainer makes assumptions about 
>the image notation handler.  IOW, sometimes, the notation declaration 
>*is* needed and I am getting confused if the notation of the 
>content type (e.g, the tiff, gif, VRML is indicated).

Yes, because I was using a URL directly to address the image (and not an
entity whose system identifier was a URL), I lost the notation declaration.
 Of course, we can depend on MIME types to make the proper association, right?
 
>BTW, are you assuming the use of a URL resolver?  In the #prefix
>convention, 
>a lot of strings are appended to the locator, and that assumes one knows 
>what strings are available. 

I'm not sure what you mean.  I thought use of URLs (and therefore support
for their resolution) was a hard requirement for XML.

                              So, for management's sake, how does the 
>example look if one is pointing out of a document instance into the 
>independent link set document using a URL? Is it as simple as appending 
>the name of the linkset document plus the  link id to the URL with the 
>proviso that the linkset document handler knows to goto/gosub/spawn 
>the target?  

Again, I'm not sure what you mean.  Do you mean linking from a document to
an independent link? You'd address it just as you would anything else: but
note that addressing a link doesn't necessarily cause anything to happen:
you're just addressing the link as another element.  In HyTime, at least,
links only cause behavior when traversal between link ends happens.

                 Sounds like a catalog.  From a management perspective, 
>BOS management is catalog management and all the document instance 
>needs to know is the name of its catalog.

I think you can think of it that way: the BOS is nothing more than a list
of the entities that need to be examined for possible links and link ends.
As the HyTime BOS is determined by the entities *declared*, not the
entities referenced, you can define a BOS using a trivial document that
declares all the entitites in the BOS and then contains a single contextual
link to the first starting point of the real data (and even this last isn't
strictly required, although it's sort of implied by the current wording of
the standard--but an application is free to provide whatever access
behaviors it wants, including letting the reader select from a list of
available documents, e.g., what DynaText does when you open a collection.),
e.g.:

<!DOCTYPE BOSCatalog [
 <!ELEMENT BOSCatalog EMPTY >
 <!ATTLIST BOSCatalog 
           linkend    CDATA #REQUIRED
 >
 <!NOTATION XML PUBLIC "-//W3C//NOTATION Extensible Markup Language//EN" >
 <!-- XML derived from SGML notation -->
 <!-- Documents in BOS defined by this document -->
 <!ENTITY doc1  SYSTEM "..." CDATA XML >
 <!ENTITY doc2  SYSTEM "..." CDATA XML >
   ...
 <!ENTITY docn  SYSTEM "..." CDATA XML >
]>
<BOSCatalog linkend="http://www.me.com/index.xml"/>

Cheers,

E.
--
W. Eliot Kimber (eliot@isogen.com) 
Senior SGML Consulting Engineer, Highland Consulting
2200 North Lamar Street, Suite 230, Dallas, Texas 75202
+1-214-953-0004 +1-214-953-3152 fax
http://www.isogen.com (work) http://www.drmacro.com (home)
"Rats in the morning, rats in the afternoon...if they don't go away, I'll be
re-educated soon..."                 --Austin Lounge Lizards, "1984 Blues"

Received on Monday, 30 December 1996 13:53:08 UTC