RE: Documenting implicit assumptions?

Not for Henry (he already knows all this about me and my lot of users).
 
Some of the discussions so far contributed are excellent, helping me focus on "the legacy issue" in my particular case. And, its more than just need to perhaps work with legacy SSL, or the million "legacy" certs we already consume. There is the issue of legacy "data," too. Is support for legacy data practices "in scope". This means addresing those XML data sets!
 
Folks may have picked up that Im a fan of RDFa theoretically marking up the few million home pages our users maintain; and then letting the webid in SSL messages, a self-signed cert, or an HTTP request , or elsewhere (e.g. an audit record) point to that page . While we have lots of those pages to worry about, the backroom data services are not static web pages. They are part of the usual "dynamic web" page world. They are XML membership records (think SQL..) that drive an XHTML renderer. (I think there was once an W3C standard or two promoting this model.) ION heneral, SQL drives XML, drives XHTML. It can just as easily then drive XHTML+RDFa, or just output XML+RDFa.
 
So my issue goes to the heart of the semweb angle here. So farm 90% of the talk has been about ciphering, SSL, certs, etc. Lets focus back on data for a monent. Will the scheme target XML data sources, or will it only focus on native RDF data stores ...or static HTML home pages marked up with RDFa?
 
For the first time yesterday, I understood that the RDFa markup we contemplate here - though characterized in terms of enhancing "home pages" - might also apply to apply to XML result-sets . So long as the result set is conforming XML (which it is), its the nature of RDFa is - if I get it right - that it can super-tag any well-formed XML.  That is... we can mark up the values with the RDFa tags , so calling out the rsa integers, and oddities like the cert:identifier needed to make thje stream act as an RDF data stream ...and thus supprot the sparql query used by the server consuming the webid protocol. Its not that we will be adopting triples stores, or doing any reasoning, or... doing any of the stuff far too advanced for us SQL-types to understand (whats entailment? whats reification?). But, as grunts, we certainly can tag stuff... to help promote adoption of the standard. And, there is a lot of data to tag!
 
So, as I think about the topic of "documenting implicit assumptions", it seems to me that we may put into our users' existing certs (when we re-issue them) a webid that is just an http query to that data service, bound into an http URI. If the query's parameters are set to require a unique result, one XML value will occur in the resultset. 
 
Now, knowing my community, we probably will never conform to the latest "web architecture" or even use HTTP content-negotiation features  from the architecture of 10 years ago - when asking the server to markup that XML result-set with (or without) the RDFa tags. Folks will want to do what the sparql protocol world does, and indicate resultset markup requirments using query-string values on the query URI.
 
These are just some of the assumptions I have, coming in to this group. I have many, many more, if I wear my realtor-vendor hat. 
 
 
 
> From: henry.story@bblfish.net
> Date: Tue, 1 Feb 2011 00:33:43 +0100
> To: public-xg-webid@w3.org
> Subject: Re: Documenting implicit assumptions?
> 
> 
> On 1 Feb 2011, at 00:07, Peter Williams wrote:
> > Here is one attempt that took me less than 30m. It captures something of things I dont like about Henry's conception - understanding that its just a strawman.
> > http://yorkporc.wordpress.com/2011/01/29/foafssl-variation-secure-following-theorem-crt-files/
> 
> If you propose it I'd suggest opening a new thread. There you can add the following
> to help people along: 
> - I don't see a section explaining why this is useful. That should come at the top. 
> - What does this protocol gain us over what we have now? 
> - Adding a UML Sequence diagram too would help understanding.
> 
> Anyway, no need to look at it too deeply if it's just a off the cuff thing you
> wrote down on a piece of paper and have no serious intention to work on further.
> I can already see about 5 issues I would have with it by perusing it quickly, one
> of which is massive increase in complexity.
> 
> 
> Henry
> 
>