Re: About URNs and Meta content

Andrew Daviel wrote:
> Re.   MCF embedded into a HTML file, since DC is settling on
>   <meta name="DC.creator"  content="Conan Doyle">
> (with some wrangling about where to put SCHEME)
> and we already have well-established
>   <meta name="description" content="detective stories">
> I thought perhaps one might use e.g.
>    <meta name="MCF.authorIndividual"  content="Conan Doyle">

good point.

> In the comment version (waiting on new tags), it's hard to see how
> to parse the MCF distinct from random comments, JavaScript, etc.

A tag would be needed...  I'm not convinced we need MCF in the html body
unless we are assigning meta info to segments of the body.  Markups
would make more sence for that case.  e.g.

<mcf profile="XYZ.product">
   <slot name="productDescription"> yoyo </slot>
   <slot name="productPrice"> $39.95 </slot>
</mcf>

would be equivalent to a meta file defining those attributes
> 
> In the mail-header version there's nothing to identify the
> X-info as MCF, to distinguish it from all the other stuff like
> X-Mailer, X-Comment, X-Face, X-Report-Type etc. that turns up in my
> mailbox.  How about  X-MCF.TocOf  etc. ?

another good point.

> Re. http transport; correspondance I have had from Roy Fielding suggests
> that one shouldn't invent arbitrary random HTTP headers; the
> "X-" convention is undefined in RFC 2068.

Let's not be arbitrary! "X-" in this case looks like a valuable addition
to RFC 2068.  It can do for HTTP what it did for mail, provide dynamic
extensibility.  Hopefully we won't abuse it...

> Meanwhile, some DC people say they're going to move to PICS or XML
> in a year or two, and I thought I was confused enough already ... :-}

Presently PICS is confined to self information.  I can't get meta info
about yahoo from Apple using PICS.  We can, however, integrate PICS
profiles/shema into MCF.  XML would provide a way to define HTML to MCF
mappings like my example above, but has the same problem as PICS.

RFC822 syle MCF might not be the only meta-content specification we will
want, but it provides generality, simplicity, consistancy, and
imbeddability into existing protocols.  New protocols might include it
intrincically.  General mappings to SGML, ASN.1, X.12, KIF etc., and
specific mappings such as to PICS, EDI, IDL, LDAP, etc. are not yet
specified, but these concerns go beyond defing a simple flat file format
for meta info.

With your segeestions incorporated, the 1.1 MCF is lookinging cleaner.

jim

Received on Friday, 21 March 1997 14:21:48 UTC