Re: Review of "Base URIs and GRDDL"

Summary, all suggestions accepted except for the suggestion to excise 
this sentence:
[[
In many applications of GRDDL, the possibility of GRDDL results that 
depend on the application default URI is highly undesirable; GRDDL aware 
agents may choose to treat this case as an error.
]]
Given the excision of its context, I think maybe changing it to:
[[
In many applications of GRDDL, the possibility of GRDDL results that 
depend on an application default URI, from section 5.1.4 of RFC 3986, is 
highly undesirable; some GRDDL aware agents may treat this case as an error.
]]
is that agreeable?

====

A further question: should we call out with a reference to 
XHTML+MATHML+SVG and CDF as examples of XHTML family documents in which 
an xml:base may legitimately appear, this would have the side-effect of 
lengthening the informative references of the spec.

====

Question to DanC:
given the plan to move this to be an informative appendix to the spec, 
what would you like me to do:

various editing tasks:
a) fold in John's changes
b) fix @@@s
c) move text into spec
d) check references work

Jeremy



Clark, John wrote:
> I took an action to review Jeremy's base document[0]:
> 
>   ACTION: john-l to review http://www.w3.org/2001/sw/grddl-wg/base
> http://lists.w3.org/Archives/Public/public-grddl-wg/2007Jun/att-0113/13-
> grddl-wg-minutes.html#item11
> 
> Overall, I think that this document helps to clarify the issues
> surrounding the relationship between IRI processing and GRDDL.  My
> detailed comments follow.
> 
> <review>
> Review of "Base URIs and GRDDL"
> ===============================
> 
> Substantive suggestions
> -----------------------
> 
> From section "The Base IRI used for processing GRDDL Results"
> .............................................................
> 
>   - "To convert this serialization into an RDF graph, a base IRI
> parameter
>     is often needed. To identify the appropriate base IRI, first ..."
>     ->
>     "To convert this serialization into an RDF graph, relative
> references in
>     the serialization first need to be resolved into IRIs.  To identify
> the
>     appropriate base IRI for resolving a given relative reference, first
>     ..."

Accepted.

> 
>     Rationale: clarify language, avoid "parameter" language that has
> been
>     shown to confuse XSLT authors.
> 
>   - "If there is no such base, then, because this serialization has an
>     encapsulating entity, section 5.1.2 of RFC 3986 applies, and the
> base
>     IRI of the original document is used as the base IRI of the
>     serialization."
>     ->
>     "If there is no base URI embedded within this RDF/XML, then section
>     5.1.2 of RFC 3986 may apply, because the encapsulating entity of
> this
>     serialization is the root element of the input document.  If this 
>     element does not define a base URI, then its encapsulating entity,
> the
>     input document, may define a base IRI."

Accepted.

> 
>     Rationale: attempt to make this description more accurate,
> particularly
>     in pointing out that the encapsulating entity is the root element of
> the
>     input document (which is itself contained in the document itself),
> as
>     illustrated by test case #xmlbase1
>     (<http://www.w3.org/2001/sw/grddl-wg/td/grddl-tests#xmlbase1>).
> 
> From section "The Base IRI of an XHTML Family document"
> .......................................................
> 
>   - "the base IRI may be specified"
>     ->
>     "the base IRI of the input document may be specified"

Accepted.

> 
>     Rationale: clarify the scope of the HTML `base` element.
> 
> From section "The base IRI of other XML documents"
> ..................................................
> 
>   - "Specifically, XML Base should not be used with XHTML family
> documents."
>     ->
>     "Specifically, `xml:base` attributes should not be used on elements
> in
>     an XHTML namespace."

Accepted, I think given the recent discussion, that I would prefer 
informative references to CDF or XHTML+SVG+MATHML but that would be more 
references which may be unwise.

> 
>     Rationale: As we have seen recently, compound documents may
> incorporate
>     support for `xml:base` in some component dialects, but we are only
>     really interested in discouraging use of `xml:base` on the root
> element
>     when that element is also an XHTML element.
> 
> From section "GRDDL aware agents"
> .................................
> 
>   - Comments: This section confuses me.  In the first section, you
> mention
>     that we can look "for a base URI embedded within this RDF/XML,
> following
>     XML Base, as permitted by RDF Syntax", but here you say that
>     "[f]ollowing the analysis above, this base URI is the base URI of
> the
>     original document."  It seems like this whole paragraph should
> instead
>     read as follows:
> 
>     "Following the analysis above, a base URI for resolving a relative
>     reference is defined by following section 5.1 of RFC 3986."
> 
>     I would purge the remaining paragraphs in the section (except for
> the
>     last paragraph), as they all seem to reiterate the earlier
> discussion to
>     which we refer the reader with "[f]ollowing the analysis above ...".

Accepted, except for this sentence, which I don't think is a duplicate:
[[
In many applications of GRDDL, the possibility of GRDDL results that 
depend on the application default URI is highly undesirable; GRDDL aware 
agents may choose to treat this case as an error.
]]
Given the excision of its context, I think maybe changing it to:
[[
In many applications of GRDDL, the possibility of GRDDL results that 
depend on an application default URI, from section 5.1.4 of RFC 3986, is 
highly undesirable; some GRDDL aware agents may treat this case as an error.
]]

and I take the last sentence that you are happy with to be the next one, 
starting "Note: ..."


> 
> Minor edits
> -----------
> 
> Overall
> .......
> 
>   - The title of the document is "Base IRIs in GRDDL", but the first
> header
>     calls it "Base IRIs and GRDDL".

Accepted.
> 
>   - It would be good to have a version number for the document listed
>     somewhere.

I'll put an ID in, but I am assuming it will get into the spec editor's 
draft soon.

> 
> 
> From section "The Base IRI used for processing GRDDL Results"
> .............................................................
> 
>   - "The GRDDL specification, says" -> "The GRDDL specification says"
> 
>     Rationale: punctuation nitpick

accepted
> 
>   - "serilization" -> "serialization"
> 
>     Rationale: spelling fix

accepted
> 
> From section "The base IRI of other XML documents"
> ..................................................
> 
>   - "Other XML documents may have used XML Base."
>     ->
>     "Other XML documents may use XML Base."
> 
>     Rationale: fix strange use of past perfect tense.

accepted

> 
> From section "Document authors, including profile and namespace
> documents"
> ........................................................................
> ..
> 
>   - "specifying an in-line base-URI"
>     ->
>     "specifying an in-line base URI"
> 
>     Rationale: punctuation nitpick
accepted - and all the following too

> 
> From section "GRDDL transformation authors"
> ...........................................
> 
>   - "When writing a GRDDL transformation for an XML document format,
> that
>     does support xml:base"
>     ->
>     "When writing a GRDDL transformation for an XML document format that
>     does support xml:base"
> 
>     Rationale: punctuation nitpick
> 
>     Note: It would be good to consistently use the markup highlighting
>     attributes such as `xml:base`.
> 
>   - "Transforms that do this, need to guard"
>     ->
>     "Transforms that do this need to guard"
> 
>     Rationale: punctuation nitpick
> 
>   - "For example a xml:base=".." on the root element, might, in the
>     interaction between a correct GRDDL aware agent, and a poorly
> written
>     transform, ..."
>     ->
>     "For example, an xml:base=".." on the root element might, in the
>     interaction between a correct GRDDL aware agent and a poorly written
>     transform, ..."
> 
>     Rationale: punctuation nitpicks and consistent use of articles
> 
> From section "Library support"
> ..............................
> 
>   - "This library includes three named templates, that generate
> attributes
>     in the XML namespace."
>     ->
>     "This library includes three named templates that generate
> attributes
>     in the XML namespace."
> 
>     Rationale: punctuation nitpick
> </review>
> 
> [0] http://www.w3.org/2001/sw/grddl-wg/base
> 
> Take care,
> 
>     John L. Clark  |  Systems Analyst
>                    |  Cardio-Thoracic Surgery Research
>  Cleveland Clinic  |  9500 Euclid Ave.   |  Cleveland, OH 44195
>                    |  (216) 445-6011
> 
> ===================================
> 
> 
> 
> 
> Cleveland Clinic is ranked one of the top 3 hospitals in
> America by U.S.News & World Report. Visit us online at
> http://www.clevelandclinic.org for a complete listing of
> our services, staff and locations.
> 
> 
> Confidentiality Note:  This message is intended for use
> only by the individual or entity to which it is addressed
> and may contain information that is privileged,
> confidential, and exempt from disclosure under applicable
> law.  If the reader of this message is not the intended
> recipient or the employee or agent responsible for
> delivering the message to the intended recipient, you are
> hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited.  If
> you have received this communication in error,  please
> contact the sender immediately and destroy the material in
> its entirety, whether electronic or hard copy.  Thank you.
> 
> 
> 
> 

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

Received on Tuesday, 19 June 2007 20:27:03 UTC