RE: ACTION-156: Review of

Hello Noah,

> -----Original Message-----
> From: []
> Sent: 04 September 2008 14:23
> To: Williams, Stuart (HP Labs, Bristol)
> Cc:
> Subject: RE: ACTION-156: Review of


> I'm out of time at the moment, but as noted in private email earlier, I'd
> still be curious to know for which of the other issues you've raised you'd
> actually look for changes in the draft, and where possible, some guidance
> as to what those changes might be.  Thank you!
> Noah

Modulo the editoral problem of getting the list of activity associated with a typical request/response to read comfortably, I can live with section 2.

I remain mildly uncomfortable at the use of the word 'nature' for the reasons given - that it alludes to something grander that mere media-type determination and selection of the appropriate client side handler, and if that grander something is what was intended then the example should be illustrate that. However, I can live with it.


My section 3 comment is the subject of a separate message - an I expect that we will resolve that.


Re 4.2 URI Based Extensibility (anal) comment on:

"This [dynamic spec discover, implementation...] is done by:
 - ensuring that every specification, and in many cases each markup tag or data value used, is identified with a URI."

Maybe we are talking at cross purpose. Maybe you are talking about the markup and data values used in the specifications themselves - eg XPATH/XQuery establish URI both for a bunch of functions and operators, but also the corresponding part of the specification document that describe each function/operator.

I thought that you were talking about either XML scheme defined elements or attributes (hence mention of SCUDs to remind that URI naming of tags and attributes is not as easy as it might seem) OR that you were talking about URI naming of the occurence of tags (and maybe attributes) and their content/values - in which case I've concede that assignment of IDs and XPATH at least can be used to do that - but that's not as obvious as simple NS:localname combination which is what I took to be roughly implied in the bullet.

Anyway - I'll be satisfied with an acknowledgement that on close reading the claim in the first bullet bears the crisism I've given it (anal though it may be).


Re:  4.2.2 Microformats: (Question of information)

I asked the question of whether the 'follow-your-nose' story associated with the profile attribute is actually grounded in the HTML specs (multiple of them and in non-conflicting ways). I haven't done the checking... I've merely asked the question. I'll be happy with the answer that yes indeed the grounding is widely supported by the HTML specs.


Re: 5 RDF and the Self-Describing Semantic-Web: 2nd para:

I gave a critical reading which I can set asside in favor of a less critical reading. I'd prefer that we find a way not to leave the text open to the more critical reading (which is hard to do), but I'd we willing to live with it as-is if we are not able to improve it.


Re:  Section 5 3rd para: (anal)

I responded with a suggestion:

> > Suggestions?

> " directly obtain RDF triples that represent or indirectly obtain RDF triples
> that describe the referenced resource."
> ..though I can live with the original though I can read it two ways only one of which I think is correct.


Re: Section 5 RDF source fragment (editorial)

I'm open either way, though I think that for something illustrative N3 is way clearer than RDF/XML and particularly so for the XML'ararti who generally find making sense of RDF/XML something of an alien task. Ok this example is small and without much in the way of RDF'isms though it does use the "Typed Node Syntax" of



Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Thursday, 4 September 2008 16:38:03 UTC