Re: SOAP Requirements

Jared_Rhine@hmc.edu
Errors-To: listmaster@www0.cern.ch
Date: Wed, 23 Mar 1994 12:11:20 --100
Message-id: <199403231108.DAA22797@osiris.ac.hmc.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: Jared_Rhine@hmc.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Jared_Rhine@hmc.edu
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: SOAP Requirements 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 6437

JRhine> It seems likely that the metainformation for the SOAP should be kept
JRhine> external to the document itself.  Assuming use of the HTTP protocol
JRhine> as the transfer method (as my prototypes do), I think the HEAD
JRhine> information should probably be generated from information external
JRhine> to the document.  Although this introduces some problems with
JRhine> respect to keeping all the documention information "in one place", I
JRhine> think the difficulties associated with hard-coding the information
JRhine> in the document are far greater.

JRhine> Given that, it seems that a good location for the SOAPs would be by
JRhine> using the META tag of HTML+.  As such, the entire line must conform
JRhine> to RFC822 so that the HTTP protcol can transfer it as header field
JRhine> (key: value).

Roy> The above two paragraphs are contradictory.  The META element only
Roy> exists within HTML+ documents and thus using META for this purpose
Roy> would necessitate embedding that information within the document.

I may have phrased things in an unclear manner, but I don't believe the
ideas themselves are contradictory.  While I am, of course, forced to agree
that the META tag proper belongs solely to HTML+, I was thinking more in
terms of what that tag does (currently); it provokes a HTTP transaction
header (or at least that's the semantic value in which I'm currently
interested).

The model I'm proposing is to construct the information that would normally
be contained within the META tag via a dynamic lookup on a distributed
database backend (the RLS).  Thus, HEAD information provided in both the
HEAD and GET methods (and others, as appropriate) would not be derived
directly from the document, but instead from an external source.  The
document would have certain items fixed (such as its identifier in the
namespace; basically its URN) via the HTML+ META tags, but other
metainformation would be stored external to the document, as it must be (can
anyone seriously suggest encoding SOAPs into the document itself?)

Roy> Such a solution would also be inadequate for non-HTML documents
Roy> (e.g. MPEG movies or GIFs).

I certainly don't see why that is the case; if the transactions headers (the
moral equivalent of the META tag, in my mind) are constructed from
information external to the object, how in any way would that not apply to
MPEGs or GIFs?

Roy> What you really want is a metainformation table -- something that can
Roy> be loaded by the server (either on a per site or per document basis)
Roy> and which contains the list of SOAPs (and/or other metainfo) for each
Roy> document+version.  Note that version is important because a SOAP should
Roy> only be applied to a particular version of a document (not all
Roy> documents of that name).

I want something slightly more complex than a table; I want a dynamic
database query, possibly constructed from information obtained via
distributed means (not every server will be able to store all the
information for all documents).  There is a variety of other information
besides SOAPs that would need to be implemented, as well. I don't think a
table would scale well; providing the information "on a per site or per
document basis" isn't really what I'm after.  The document publisher should
be the final arbiter of the metainformation (aside from SOAPs; a publisher
can not chose to prevent a SOAP from being attached to the document).  The
mechanism to retrieve that metainformation should incorporate the idea of a
"canonical" source, with TTLs among secondary servers.  As I said, the best
model I've seen so far is DNS.

Note also that the Interpedia project has not (yet) made the assumption that
a SOAP must expire when a document version changes, since the question of
implied SOAPs is still open.  Yes, yes, it seems the logical thing to do,
and many documents will operate that way by default, but I have yet to be
convinced that it applies in all cases.  I won't sacrifice SOAP reliability
to gain a minor advantage, though.

JRhine> Thus, roughly, for an enumerated SOAP, the HEAD of a document would
JRhine> contain
JRhine> 
JRhine> <meta
JRhine> name="x-SOAP#American_Children's_Association!suitable-for-children"#
JRhine> value="boolean#true">

Roy> Yuck!

No kidding; I wasn't particularly happy with it either, which is why I asked
for feedback, which I appreciate.

Roy> That would result in a header like:

Roy> x-SOAP#American_Children's_Association!suitable-for-children: boolean#true

Roy> which is not what an rfc822-type header should look like.

Agreed.  I still think we need the separator, so I'll still keep the
exclamation reserved.  After rereading the RFC at some reasonable hour (only
3 AM tonight instead of last nights' 5 AM :), the colon doesn't need to be
reserved either.

Roy> Instead, it should be like

Roy> SOAP: American_Children's_Association!suitable-for-children=true,
Roy>       American_Children's_Association!reading-level=8

Is there any particular advantage to grouping all the SOAPs on a single
header field instead of using multiple header fields, one per SOAP?  I'd
prefer the latter method unless there is some overiding reason not to use
it.

Roy> I don't think that you need to (or even should) encode range or typing
Roy> information in the header -- that should be defined by the name of the
Roy> SOAP as part of some SOAP name registry, i.e.  all SOAPs ending in
Roy> "suitable-for-children" have legal values of (true,false).

Yeah, I can see arguments either way.  I was trying to get away from having
all new SOAPs have to become some sort of "standard".  Great, this SOAP
issuer wants to issue a SOAP of this type (where the range is defined in
some manner).  They flat out _can't_, because neither the browser nor the
client has the semantic value of that SOAP encoded in their static table.
The ICC could try to approve a list of different types, but no list is ever
complete.  It seems probable that the number of different types would reach
some plateau and then grow only _very_ slowly.  Given this assumption, using
a static encoding of SOAP names could probably work.  I've just never been a
big fan of "registries".

--
Jared Rhine         Jared_Rhine@hmc.edu
wibstr              Harvey Mudd College
                    http://www.hmc.edu/www/people/jared.html

"Come, let us retract the foreskin of misconception and apply the wire
 brush of enlightenment." -- Geoff Miller