[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: RESTful operations on document fragments

  • From: "Anne Thomas Manes" <atmanes@g...>
  • To: "Len Bullard" <len.bullard@u...>
  • Date: Fri, 22 Feb 2008 20:34:56 -0500

Re:  RESTful operations on document fragments
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@u...> 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@s...]
>
>
>  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@l...
>  subscribe: xml-dev-subscribe@l...
>  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@l...
>  subscribe: xml-dev-subscribe@l...
>  List archive: http://lists.xml.org/archives/xml-dev/
>  List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.