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

[Todd Tillinghast]

Steve,
> 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>
> 

Agree, we should keep <a> for the sorts of things you mention above.

It makes me a little nervous encoding references that are likely to be
transient, but that is up to the encoder to determine the degree to
which the document should be timeless.

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