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

[Todd Tillinghast]

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

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.

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.

We can create a service that serves up content based on SOAP messages,
queries presented via http requests, as well as a number of other
mechanisms, NONE of which have anything to do with an <a> type hyperlink
behavior.  The software using the osis document can create these kinds
of behaviors, including simple style sheets.

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.


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.

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