FWD: SGML URC spec comments (2/4)

Neither Brian or I have a complete copy of my reply to his
questions on the URC spec. The message below is my attempt
to reconstruct that reply, based on my recollection and
the material Brian quoted in his response to the original
version of this message.


----------------
Hi Brian,


Thanks for the quick turnaround on your comments. May I have your
permission to forward your message to the URI list?

> > The N2 and L2 operations are sent at HTTP GET requests. The C2C
> > operation is sent as an HTTP POST request since it is likely
> > to be quite large.
>
> Well, in the object-oriented model, "POST" is not just a way to send more
> information up the pipe in the request.  "POST" is defined to be an action
> which modifies a resource or creates a new resource; thus, the request and
> the response is never cached automatically.  Meanwhile, "GET" is defined to
> be idempotent - it doesn't change anything, and thus it can be cached and is
> considered "safer".  Now, you and I know that there are scripts out there 
> that violate this - I've built several myself.  However, the 
> object-oriented model is something we should try and keep sacrosanct, in 
> specification at least.

Yeah, GET would be the clean choice, I just recall having argument length
problems with it. I haven't tested any of the new servers for such problems.
Do you know what the limits are for Apache?

> Where does x-dns-2 come from?

Mitra had a URN proposal thta used domain names. Paul Hoffman and I
modified that proposal, thus dns-2. The x- is because it is all
still very experimental.

> I like the "Server: Apache 2.7 header :):)

Yeah, that was fun.

> > Synchronization: Synchronizing the content of multiple URC
> > servers is outside the scope of this specification.
> 
> This is bad - I didn't see anything (on first glance) that
> deals with expiration and redundancy. DNS only works because
> of this. Or maybe this is just for a different spec?

Yeah, this spec just addresses the communication between a
URC server and a client.

> Hmm. I
> see URCs as analogous to DNS's SOA records, so I don't think it
> would be inappropriate here.


Hmmm. I don't see URCs as analogous to SOAs, at least as far as I know about
SOAs. An SOA implies authoritative information. I don't regard URCs as
authoritative. Which is more authoritative - the publisher's URC for a
resource, the Library of Congress' (which will be prepared to a higher
standard), or any of the other URCs that can exist for a resource. This is
related to a later question of yours about non-publisher supplied metadata.

> some mention of or pointer to or a description of a methodology for
> "common objects". This is not at all important to the document world,
> but for VRML it's crucial.

I recall seeing a message introducing the URI and VRML groups that
I still mean to respond to. Since anyone can publish a URC, I
think the system can handle this.
If the VRML folks define a naming scheme, and basic URCs for common
objects, VRML developers could use those names, provide URLs for their
own objects, and away you go.


> 2) Using URC's to contain non-publisher-supplied metadata, particularly
> comments and "global annotations".

This issue keeps coming up, so I am not doing a good job explaining
that anyone who wants to can establish a URC for a resource. It is just
a question of how to find it.

The publisher's URC is the "default" URC for a resource since under
most URN models, the publisher's name is used in the resolution
process. However, I could have a browser that talks to a particular URC
resolver by default, such as the one at the schools firewall that
snarfs the PTA's URCs nightly. I could use a URL to connect to OCLC's
URC server, give it a URN, and get their URC for the resource.

> I think URC's would be the perfect vehicle for the web to become
> writable - so that any page I visit I could attach commentary to
> (or more precisely, create  a child document, host it on a server
> *somewhere*, and have the URC contain a child that points to it).

Have you seen the PRDM work out of Stanford? Take a look at
<URL:http:// www-diglib.stanford.edu/rmr/TR/TR.html> if not. This is
the sort of annotation system that I have in mind.

> Compelling applications!  That's all you need, history tells us :)

True, quite true.

-- 
Ron Daniel Jr.                email: rdaniel@acl.lanl.gov
Advanced Computing Lab        voice: (505) 665-0597
MS B-287  TA-3  Bldg. 2011      fax: (505) 665-4939
Los Alamos National Lab        http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM,  87545    tautology: "Conformity is very popular"

Received on Friday, 23 June 1995 14:50:23 UTC