Re: [xml-dev] RESTful operations on document fragments

["Anne Thomas Manes" <atmanes@gmail.com>]

You could always add an abstraction layer that maps URLs (resources)
to document fragments. In your Bible example, you could define a
resource for each verse in the document. Therefore you can PUT an
updated verse, and a bit of code would then update the appropriate
document fragment.

I believe that fragments (#xxxx) are different from queries (?xxxx). A
URL containing a query string is still a URL. A fragment is not part
of the URL (see
http://www.w3.org/TR/WD-html40-970708/htmlweb.html#h-4.1.1).

Anne

On Fri, Feb 22, 2008 at 5:51 PM, Len Bullard <len.bullard@uai.com> wrote:
> This was the same challenge in HyTime which is why resolvers were separated
>  from the link itself (I've forgotten the formal terminology.).  Hytime went
>  off the rails because of a) excessive abstraction and b) extending it to
>  mean all formats therefore the need for resolvers in any kind of data format
>  or system for that matter.
>
>  It's tough to get around NOTATIONs realistically even if you wedge new
>  syntax and naming into it.  Somewhere, the link has to point to the address
>  (no names and locations aren't the same thing), and the address has to be
>  passed to a resolver that can return something from the data format it is in
>  to a consumer that can read what is returned.
>
>  I know you know all of this.   I just don't know quite how one extends the
>  addressing possible without opening that can of worms.
>
>  len
>
>
>  From: Simon St.Laurent [mailto:simonstl@simonstl.com]
>
>
>  However, document fragments are typically identified through the
>  fragment identifier, the #xxxx that is the usual domain of tools like
>  XPointer.  The fragment identifier is not normally sent to the server,
>  and is supposed to be processed on the client side, depending on the
>  MIME type of the response. [3]
>
>  That makes good sense in the GET context which has been typical of most
>  Web operations.  However, it raises a challenge in the RESTful
>  processing context.
>
>  Am I required to perform RESTful operations only against a complete
>  resource?
>
>  <snip />
>
>
>  The problem of resource granularity seems like a question that is
>  starting to need a more general and at least somewhat flexible solution.
>
>  (Rails' current RESTfulness can dodge this because each database record
>  is treated as a resource, and that's the usual granularity developers
>  work at.  It only gets weird when you look beyond regular tables to
>  irregular documents.)
>
>  Thanks,
>  Simon St.Laurent
>  Retiring XML troublemaker
>  http://simonstl.com/
>
>  [1] -
>  <http://www.oreillynet.com/xml/blog/2008/01/rails_rest_and_anarchist_xml_1.h
>  tml>
>
>  [2] - <http://www.faqs.org/rfcs/rfc2616.html>
>
>  [3] - <http://www.w3.org/DesignIssues/Fragment.html>
>
>  [4] - <http://bitworking.org/news/296/How-To-Do-RESTful-Partial-Updates>
>
>  _______________________________________________________________________
>
>  XML-DEV is a publicly archived, unmoderated list hosted by OASIS
>  to support XML implementation and development. To minimize
>  spam in the archives, you must subscribe before posting.
>
>  [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
>  Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
>  subscribe: xml-dev-subscribe@lists.xml.org
>  List archive: http://lists.xml.org/archives/xml-dev/
>  List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>  This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.
>
>
>
>  _______________________________________________________________________
>
>  XML-DEV is a publicly archived, unmoderated list hosted by OASIS
>  to support XML implementation and development. To minimize
>  spam in the archives, you must subscribe before posting.
>
>  [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
>  Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
>  subscribe: xml-dev-subscribe@lists.xml.org
>  List archive: http://lists.xml.org/archives/xml-dev/
>  List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>