RE: neither FCNS nor FOAFSSL can read a new foaf card (hosted in Azure). RDFa validators at W3C and RDFachecker say its fine...

Ive stopped doing code related to this thread. Ill come back later to this, when things have got clearer. I just going to (i) put RDFa embedded in blogspot template (http) and (2) TTL in windows blob storage (http and https). These work. My summary is this: All I wanted to do was take the actual RDFa stream from the spec, and host it on a bog standard windows website amended for the RDFa DTD, and see webid validation work on 2 or 3 validator sites. At that I failed (though other ADVANCED cases involving workarounds did work, sometimes.) I failed to replicate a trivial unit test, that is, using a windows web server and the streams from the spec. This is worrying. Trivial replication of core use cases failed. For background and analysis: j.jakobitsch@semantic-web.at implied in (2) below that my windows system should NOT produce empty rdf, in one of the actual tests he laid out - that are proper and easy to replicate. They are good "endpoint' tests, that determine if triples can be read in all required flows. This led to the implication (and a million words) on whether THIS protocol requires a resource server's endpoints to accept #frags ON THE WIRE. This is all that differentiates endpoint (1) and endpoint (2), since both flows are triple importing (not querying). IN one case, windows fails to deliver triples. (a) I cannot tell whether a resource server for webid profiles MUST BY DESIGN for webid validation accept and handle GETS with fragments on the wire, after all the words. I though I heard Kingsely assert that it is essentialy necessary, for "true de-referencing" at a grade suited to security. It is simply flow (2) of the 2 tests. I do know Henry's server does support such behaviour. And, I suspect Henry is the author of the RDFa in the spec. We MAY have uncovered a bias (implicit requirement) in the spec.  (b) I have yet to make windows IIS server deliver a stream for a GET for URI with fragment on the wire, whether required or not for this protocol. Being fair to Microsoft, they do what the HTTP RFC says they should. But, the HTTP is indeed a SHOULD not a MUST, and thus it is not wholly improper to do what Henry's server does. The question is: IS IT NECESSARY, HERE FOR THIS (and only this) PROTOCOL So, so far, we have a unit test titled "endpoints" : do you have 4 endpoints, 2 http and 2 https, with and without fragments (on the wire). Ive failed 2 of of these endpoint unit tests, due to the nature of windows conforming to the HTTP RFC. Kingsley may solve that for me, next week, making windows/IIS non-conforming but aping Henrys server. Then, I MAY be able to stream back a serialized collection of triples for any class of GET, fragments on the wire or not. This will mean all 4 endpoints work as expected, HERE. ------ having got 2 of the 4 endpoints working, we now move onto naming, addressing and querying. 
For case 1 endpoints (that worked by delivering triples), using the actual RDFa example in the spec, none of the 3 test sites gave me a positive response. This is evidently not an endpoint issue, but a logic or naming issue. This led to doing various workarounds, which taught me a lot about 4 areas of advanced webid. But, the simple webid unit test failed. I cannot tell whether the underlying issue for the unit test failure (for the test I now title "de-referencing test" is - inability of Windows to offer endpoints that deviate from the HTTP RFC (see above), - whether the particular relative naming practices of the particualr RDFa example in the spec induces a failure at all three sites- whether the latter is ture  but ONLY when combined with the inability of Windows...of handle fragments on the wire. --------- lots of other workaround stuff worked, and showcased the true and ultimate power of webid. lots of advanced stuff got discussed. Nothing was wasted.  But, I could not do what the spec says. And, I should be able to, even with my mediocrity at programming/IT.  > Date: Wed, 28 Dec 2011 09:44:10 +0100
> From: j.jakobitsch@semantic-web.at
> To: home_pw@msn.com
> CC: kidehen@openlinksw.com; public-xg-webid@w3.org
> Subject: Re: neither FCNS nor FOAFSSL can read a new foaf card (hosted in Azure). RDFa validators at W3C and RDFachecker say its fine...
> 
> hi,
> 
> you should use http://www.w3.org/2007/08/pyRdfa/ to check your rdfa.
> 
> paste 
> 
> 1. http://b3d0c8f68475422784748b65f76b1642.cloudapp.net:8080/Aboutrel.aspx => rdf
> 2. http://b3d0c8f68475422784748b65f76b1642.cloudapp.net:8080/Aboutrel.aspx#me => empty rdf
>