[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]

Re: All of the WWW Available **Forever**



Comments Xanni:

EC>   transclude:[URL]:[date]:[segment(s)]

>   Actually, we badly need URL extensions to support partial
>   document addressing and version selection in a standardised
>   way.  If we could address ranges within documents from a URL,
>   it could be implemented using the new "Byte range" facilities
>   in HTTP. [...]

  The XML (Extensible Markup Language, the officially proposed
  _replacement_ for the HTML) makes use of TEI's 'Xptr' (Extended
  Pointer) mechanism, which makes possible both

      "bidirectional, multi-way links, as well as links to a span
       of text (within your own or other documents) rather than to
       a single point." [reference below]
  
  Ergo, I don't believe that proposing a separate URI type just 
  for textual trasclusion would make much sense. After all, why
  shouldn't we be able to refer to AND possibly transclude
  specific _regions_ within n-layer types of data?


__Ian

 ______  ______________________________________ LINKS TO EXPLORE
 <?XML!> http://www.ucc.ie/xml/

    TEI  http://www.sil.org/sgml/acadapps.html#tei
 HyTime  http://www.sil.org/sgml/
   Xptr  http://www.ucc.ie/xml/#TEI-LINK
    EPN  http://etext.virginia.edu/bin/tei-tocs?div=DIV2&id=SAXR


      XML FAQ Version 1.0.1 (May 1997)
      ______________________________________
C.13  How will XML affect my document links? 

      The linking abilities of XML systems are much more powerful
      than those of HTML.  Existing HREF-style links will remain
      usable, but new linking technology is based on the lessons
      learned in the development of other standards involving
      hypertext, such as TEI and HyTime, which will let you manage
      bidirectional and multi-way links, as well as links to a span
      of text (within your own or other documents) rather than to a
      single point.  This is already implemented for SGML in
      browsers like Panorama and Multidoc Pro. 

      The current proposal is that an XML link can be either a URL
      or a TEI-style Extended Pointer (`Xptr'), or both.  A URL on
      its own is assumed to be a resource (as with HTML); if an Xptr
      follows it, it is assumed to be a sub-resource of the URL; an
      Xptr on its own is assumed to apply to the current document. 

      An Xptr is always preceded by one of #, ?, or |.  The # and ?
      mean do the same as in HTML applications; the | means the sub-
      resource can be found by applying the Xptr to the resource,
      but the method of doing this is left to the implementation. 

      TEI Extended Pointer Notation (EPN) is much more powerful than
      the simple ID examples given above. This_sentence,_for_example,
      marked_as_a_link,_could_be_referred_to_within_this_document_as
      ID(tei-link)CHILD(3),_meaning_the_third_object_within_the_element
      labeled_tei-link_(this_paragraph).  Count the objects: a) the
      link to `TEI Extended Pointer Notation', b) the remainder of
      the first sentence, and c) the second sentence.  If you view
      this file with Panorama you can click on the highlighted
      sentence above, which links to the start of this question, and
      then click on the cross-reference button beside the question
      title, and it will display the locations in Extended Pointer
      Notation of all the links to it, including the previous
      sentence.  (Doing this in an HTML browser is not meaningful,
      as they do not support bidirectional linking or EPN.)
         [....]