/.well-known/resourcesync or /.well-known/resourcesync.xml ?

[Simeon Warner]

I wonder whether we should consider using /.well-known/resourcesync.xml
(with the .xml suffix) instead of the the current
/.well-known/resourcesync [1]? The motivation would be to enable someone
to use a simple web-server setup for ResourceSync where the MIME type is
inferred from the extension. It would also likely lead to more
consistent naming along with all the other capability documents which I
imagine in most implementations would be given .xml extensions.

There is precedent for using an extension in the host-meta.json
registration [2] defined by RFC6415 [3]. However, I note that host-meta
without an extension is used for an XML document.

Cheers,
Simeon




[1] http://www.openarchives.org/rs/0.5/resourcesync#wellknown
"10.3.1. .well-known URI

The well-known URI [RFC 5785] /.well-known/resourcesync is defined for
the ResourceSync framework. When dereferenced, the representation
obtained will be either a Capability List document or a Capability List
Index, and thus provide a mechanism for Destinations to discover the
capabilities offered by the Source without any prior knowledge."

[2] http://www.iana.org/assignments/well-known-uris/well-known-uris.xml

[3] http://tools.ietf.org/html/rfc6415#section-6.2

[Herbert van de Sompel]

This has come up before:

- The previous spec had /.well-known/resourcesync.xml as a result of
feedback from - I think - Bernhard against /.well-known/resourcesync
- The current has /.well-known/resourcesync as a result of feedback
from - I think - Graham - against /.well-known/resourcesync.xml

;-)

Herbert

> --
> You received this message because you are subscribed to the Google Groups
> "ResourceSync" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to resourcesync...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



--
Herbert Van de Sompel
Digital Library Research & Prototyping
Los Alamos National Laboratory, Research Library
http://public.lanl.gov/herbertv/

==

[Simeon Warner]

Thanks for the reminder... maybe we'll go round a few more times ;-)

Cheers,
Simeon

[Graham Klyne]

I'm not sure that I previously argued against the .xml suffix specfically,
though I'd lean slightly against its use (e.g., I know it's not a current issue,
but that might be seen to preclude the option of using content negotiation for
future extensions).

But I have suggested in my comments that .well-known does not need to be a
primary discovery mechanism.

#g
--

[Simeon Warner]

On 2/12/13 1:20 PM, Graham Klyne wrote:
> I'm not sure that I previously argued against the .xml suffix
> specfically, though I'd lean slightly against its use (e.g., I know
> it's not a current issue, but that might be seen to preclude the
> option of using content negotiation for future extensions).

I thought about the conneg case but it seems we could later
add/change-to .well-known/resourcesync for conneg if the spec were
extended to support multiple formats. For now we explicitly have only
the sitemap XML format and that is why I thought having the .xml suffix
was nice.

> But I have suggested in my comments that .well-known does not need to
> be a primary discovery mechanism.

I saw your comment (included below [2]) but wasn't convinced that your
argument for discovery via conneg leads to an easier to implement
solution. I agree that .well-known would only be useful in cases where
there is root access, but it seems that adding content negotiation on
the "archive URI" (which seems a bit hard to define) to get the
capability list is likely more work and would often require access to
the server config which might exclude more cases than the root access
requirement.

I think the link element [1] is a lower barrier (though less elegant)
solution to discovery via the "archive URI" (or many of them) than conneg.

Cheers,
Simeon

[1] http://www.openarchives.org/rs/0.5/resourcesync#xhtmllinkEle

[2] From Graham's 8 Feb email "Continuing review of ResourceSync spec -
section 2.2":
> Section 2.2.3, "discovery perspective"
>
> Do we really need a well-known URI?
>
> Given that one must start with some knowledge of the archive, would
> it not be reasonable for that knowledge to be its URI? Then,
> dereferencing that URI under appropriate content negotiation can
> yield the Capability List.
>
> This approach has the advantage that it does not require access the
> the service host root URI space, and can support multiple
> repositories on a host. The Capability List itself seems to me to be
> a very good way of creating a REST-style API through which further
> resources can be discovered starting with just the repository URI (as
> nicely illustrated by figure 3).
>
> This would probably require that a specific content-type be
> registered for the Capability-List so that the same URI can show a
> landing page when viewed in a browser.

[Graham Klyne]

On 13/02/2013 15:28, Simeon Warner wrote:
> On 2/12/13 1:20 PM, Graham Klyne wrote:

>> I'm not sure that I previously argued against the .xml suffix
>> specfically, though I'd lean slightly against its use (e.g., I know
>> it's not a current issue, but that might be seen to preclude the
>> option of using content negotiation for future extensions).
>

> I thought about the conneg case but it seems we could later add/change-to
> .well-known/resourcesync for conneg if the spec were extended to support
> multiple formats. For now we explicitly have only the sitemap XML format and
> that is why I thought having the .xml suffix was nice.
>

Indeed... I guess the .xml suffix is mostly a matter of taste.

>> But I have suggested in my comments that .well-known does not need to
>> be a primary discovery mechanism.
>

> I saw your comment (included below [2]) but wasn't convinced that your
> argument for discovery via conneg leads to an easier to implement solution. I
> agree that .well-known would only be useful in cases where there is root
> access, but it seems that adding content negotiation on the "archive URI"
> (which seems a bit hard to define) to get the capability list is likely more
> work and would often require access to the server config which might exclude
> more cases than the root access requirement.
>

The intent wasn't so much to offer an easier-to-implement solution so much as a
more flexible approach. I don't think conneg is particularly hard on client or
server side, though that depends somewhat on the library support used. But in
some environments, using .well-known URIs might be impossible for the server.

Of course, you know all this, so I guess it really comes down to the deployment
scenarios you are most concerned to support. My own preference is to adopt a
primary discovery mechanism that is supportable in pretty much any environment
that can support ResourceSync (i.e. able to generate and publish resource lists,
change lists, etc. associated with some set of published resources.) My
previous suggestion of using conneg was intended to follow what I understand are
common REST deployment patterns.

As documented, link headers are another option which exploit link relations that
are already used by ResourceSync ... but (IIRC) this appears only in a section
at the end of the document, not in the introductory walkthrough, which seems to
suggest .well-known as the primary mechanism.

> I think the link element [1] is a lower barrier (though less elegant) solution
> to discovery via the "archive URI" (or many of them) than conneg.

Yes, that's an option, but I'm not sure I'd say lower barrier, as this requires
the client (destination) to read and parse an HTML document. I think that is
potentially a significant overhead.
...

I would also say these options are not mutually exclusive. Link headers, link
elements and conneg could be alternative ways of ending up at the same
capability list URI? .well-known could be another:

1. .well-known is easy on the client, but requires the Source to have access to
the host's .well-known configuration

2. Conneg requires Destinations to present additional HTTP request headers.
Source implementation should be straightforward (e.g. can be cone with Apache
and .htaccess).

3. Link header requires Destinations to interpret HTTP response headers. I
think server-side implementation would be straightforward in common deployment
environments.

4. As noted, Link element requirers recognition and parsing opf an HTML response.

I'd suggest that servers SHOULD (MUST?) support (2) and (3), and MAY support (1)
and (4). Clients SHOULD support at least one of (2) or (3), and MAY support (1)
and (4).

I think that all Destinations will need to be able to follow 3xx redirection
responses, so that's not included above as a consideration.

#g
--

>
> Cheers,
> Simeon
>
> [1] http://www.openarchives.org/rs/0.5/resourcesync#xhtmllinkEle
>
> [2] From Graham's 8 Feb email "Continuing review of ResourceSync spec -
> section 2.2":
>> Section 2.2.3, "discovery perspective"
>>
>> Do we really need a well-known URI?
>>
>> Given that one must start with some knowledge of the archive, would
>> it not be reasonable for that knowledge to be its URI? Then,
>> dereferencing that URI under appropriate content negotiation can
>> yield the Capability List.
>>
>> This approach has the advantage that it does not require access the
>> the service host root URI space, and can support multiple
>> repositories on a host. The Capability List itself seems to me to be
>> a very good way of creating a REST-style API through which further
>> resources can be discovered starting with just the repository URI (as
>> nicely illustrated by figure 3).
>>
>> This would probably require that a specific content-type be
>> registered for the Capability-List so that the same URI can show a
>> landing page when viewed in a browser.
>