[osis-core] osisCore_Candiate_1.1_003 - 11 osisRef URLs

Steve DeRose osis-core@bibletechnologieswg.org
Thu, 22 Aug 2002 16:34:51 -0400


At 04:06 PM -0600 08/21/02, Todd Tillinghast wrote:
>  > At 01:25 PM -0400 08/21/02, Harry Plantinga wrote:
>>  >We currently have no way to make a simple hypertext
>>  >link using the osisRef system.  We can make a <reference>,
>>  >but that's not a hypertext link.  I propose we define
>>  >a URL syntax for osisRefs.
>>  >
>>  >   a) <a href="osis:Bible.KJV:Matt.1.1">
>>  >
>>  >or, If you prefer more (and more distinctive) syntax,
>>  >
>>  >   b)  <a href="osis://Bible.KJV:Matt.1.1">
>>  >
>>  >I suppose an alternative would be to add an osisRef attribute
>>  >to the a element, so you could write
>>  >
>>  >   c) <a osisRef="Bible.KJV:Matt.1.1">
>>
>>  We added <a> a while back. I've always thought of <reference> as also
>>  having the linking semantics; but I emphatically agree we should have
>>  an encapsulation syntax for putting osisRefs into URIs.
>>
>>  The XPointer schema syntax for fragment identifiers is now in last
>>  call, and will likely issue shortly; we can be the first to leverage
>>  it....
>>
>>  http://usual.stuff.com/path/path/file.htm#osis(Matt.1.1) would do
>>  fine, on assumption the pre-"#" URI points to a version where the
>>  osisRef is applicable.
>>
>>  Even more useful would be
>>
>>  osis:... as shown above, but that requires browser mods or plugins,
>>  so shouldn't be the only way (anybody up to hacking it into Mozilla,
>>  though?)
>>
>
>I empathically believe that we should NOT have an <a> element for this
>purpose.

Can you say a bit more about why, and why it seems to be 
presentation-like? Harry did mention it getting underlined, but I 
think that was just an example -- the functional point, I think, is 
that we need a way to create cross-references that lead to things 
other than canonically-referencable documents. For example, anybody 
writing a commentary in electronic form now should be thinking about 
the option of including links to other online reference sources; and 
the only way to do those is via URIs, URNs, PURLs, etc. Since our 
<reference> isn't intended for such general uses, but to require the 
specialized reference system syntax and semantics we're defining, I 
think we still need <a>

>
>At the same time I applaud the creation of services that return little
>osis format XML documents, HTML renderings, or some other result based
>on a reference formed based on the osis standard.  To do these things we
>do NOT have to introduce <a> or similar elements and/or attributes into
>the schema.

Right; I think that's not the motivation for <a>.

>
>If we want to propose an "osis" protocol like "http:" or "ftp" then we
>can as well as defining a request syntax, then we should do that as a
>part of a SEPARATE OSIS standard.

I agree it should be separate; indeed it would need to be an IETF 
RFC, since IETF controls the internals of URIs and defines (RFC 2717, 
http://www.faqs.org/rfcs/rfc2717.html) how to register new schemes.

>Why not just create a service that can accept request via http.
>Like http://www.osis.org/request?osisRef="Bible.KJV(Bible.TEV):Ps.1.1"
>Or if you don't like the (Bible.TEV) then
>Like
>http://www.osis.org/request?osisRef=Bible.KJV:Ps.1.1&work=Bible.TEV".
>
>Or use any number of alternative mechanisms that are not as easy to type
>in a single line example.

One can do that; but the point of the <a> is for cases that aren't 
osis cases, but we still want to point to from osis documents. For 
those, clearly cheaper and easier to just use the existing 
infrastructure.

>
>
>The only place I can see having an <a> element is where text like a
>bible study includes a protocol dependant text.  Like "for more
>information on this topic visit our web site at
>http://www.abs.org/biblestudyhelps?Topic=Jonah".  I would rather see
>this is just plain text but I can see the case for an <a> element here.

Exactly! That's what it's for. More and more of the world is becoming 
"protocol dependent", especially now that URNs are finally seeing 
some use, and there are URNs to support ISBNs, ISSNs, public 
identifiers, and so on.

>
>>
>>  >In the first two examples, osis: is the protocal name, like
>>  >http or ftp.  Processing software would presumably convert
>>  >such links to regular http:// URLs in the conversion from
>  > >OSIS to HTML.

Uh, why? URL schemes need not be translated; nor need OSIS ever be 
converted to HTML; nor need one do both just because one does either. 
What am I missing?

>  > >
>>  >What needs to be done?
>>  >
>>  >   - pick a syntax
>>  >   - document it
>>  >   - for option a or b, figure out if it is possible to
>>  >     'register' the osis: protocol name
>>
>>  This is an IETF-level thing; I have the list of active RFCs in hand
>>  (well, under elbow since I'm typing), mail follows w/ pointers to the
>>  relevant ones...
>>
>>  >   - patch netscape to handle such URLs (maybe somewhat later)
>>
>>  Do you have anybody that knows their way around inside Mozilla
>>  source? I *really* want somebody to enhance it with XPointer support
>>  (can get XPointer implementation source from a faculty friend in
>>  Italy, just would need to integrate and do the open-source checkin
>>  stuff). I might be able to scare up funding for such -- certainly I'd
>>  be happy to go both ABS about all the above, since they'd all help
>>  us. I might even get up the nerve to try to bug Steve Case even
>>  though I don't know him yet.
>>
>>  >
>>  >-Harry
>>
>>
>>  --
>>
>>  Steve DeRose -- http://www.stg.brown.edu/~sjd
>>  Chair, Bible Technologies Group -- http://www.bibletechnologies.net
>>  Email: sderose@speakeasy.net
>>  Backup email: sjd@stg.brown.edu


-- 

Steve DeRose -- http://www.stg.brown.edu/~sjd
Chair, Bible Technologies Group -- http://www.bibletechnologies.net
Email: sderose@speakeasy.net
Backup email: sjd@stg.brown.edu