RE: evolution, mime, registration document posted

I've now split the document

into  components:

Concepts and Terminology: establishing a framework and terminology for use throughout the document.

Identifiers for Named Extensions: adding new values to the set of allowable values for a protocol element.

Registries: a common way of adding new values is to maintain a registry and support addition of new values

MIME: the system used in the web to name languages (and character codings)

References: the interpretation of normative links to other specifications under evolution

Background: how we got here, why is the TAG talking about this?

These are currently just placeholders:

Normative language: the use of normative language to set requirements in specifications

Versions: as things evolve, are there identifiers for points in the evolutionary stream?

Catalog: a catalog of Web language & protocol extensibility points

Natural Language analogy:  Analogy between Web evolution and natural language evolution

For this coming Thursday, my hope was that I could give a brief guided tour/readers guide through the document --
No prior reading required.

If we want to talk about any part of it, the most stable of the documents is "Concepts and Terminology".
The main thing I'm looking for are "what's missing".

At the F2F, the sections I'm most confident we could discuss practically are:

Concepts and Terminology

The "MIME product" page will be to complete the MIME page, as part of this larger context.

My hope is that the pages can evolve independently. 

-----Original Message-----
From: Noah Mendelsohn [] 
Sent: Tuesday, December 20, 2011 7:21 PM
To: Larry Masinter
Cc: Jonathan A Rees;
Subject: Re: evolution, mime, registration document posted


Thank you for the hard work on this. My impression is that there's enough here that we shouldn't expect TAG members to have read it in the few days since you've posted it, so my inclination is not to schedule formal review on this week's teleconference.  Also, the fact that ACTION-531 is not marked PENDING REVIEW, and that you've indicated that edits are happening daily, suggests that there is not a stable base for discussion just yet anyway. If we have some time at the end of tomorrow's agenda, we can always discuss this informally.

Suggestion: please set a target date of around the end of this week for freezing a version that we can discuss during the F2F. Especially with the holidays coming, I feel we need to give people more than a few days for reviewing something of this length and scope.

The other concern, which I've note elsewhere, is that I'm somewhat reluctant to have detailed discussion of this draft until we've done a bit to refocus the product page [1]. The product page should outline the scope of our work on MIME, and set out success criteria for the draft; we should review the draft in that context, I think.

Thank you again for hard work this represents, and also for checking it in with CVS (which is at best an acquired taste).



On 12/19/2011 7:16 PM, Larry Masinter wrote:
> I put the document I've been working on (evolution, registries and MIME), into TAG space.
> .html
> the document isn't stable (I'm editing it every day).
> Looking at
> I would align the two documents with this formulation (which won't make sense if you haven't read 'evolution'):
> RDF is an extensible (abstract) language for making assertions, and for which there are several concrete languages which encode and use the abstract framework.
>   RDF chose "use URI" as the extensibility method for identifiers in 
> RDF's subject, predicate, and object protocol elements (when those are not blank or literals.) The protocol element is called 'uriRef' in RDF, and I'll refer to it as the "RDF#uriRef" protocol element.
> UDDP supplies  methods  for supplying additional information can be associated with (some) RDF#uriRefs, and for accessing that information, in the form of a document.
> (The methods in the document posted are available for RDF#uriRefs 
> which use a scheme that is based on HTTP and thus has status codes, or 
> those that have a fragment identifier and a stem which can be used to 
> retrieve a representation for which the fragment identifier is 
> meaningful.)
> Other languages and protocols (besides the RDF based ones above) may choose to use the RDF#uriRef protocol element in a compatible way.
> RDF#uriRef as a protocol element shares many of the concerns discussed within the section labeled "Web Evolution: References between Specifications".
> Since the reference associated with a uriRef may change over time, and as to the decision as to the applicability of the document obtained using UDDP at a later date is left to the implementation.
> Larry

Received on Wednesday, 21 December 2011 22:14:10 UTC