RE: First Editors' draft of XML Stylesheet PI 2e

> -----Original Message-----
> From: public-xml-core-wg-request@w3.org [mailto:public-xml-core-wg-
> request@w3.org] On Behalf Of Henry S. Thompson
> Sent: Wednesday, 2009 September 16 10:26
> To: public-xml-core-wg@w3.org
> Subject: First Editors' draft of XML Stylesheet PI 2e
> 
> Simon and I have completed our respective first passes at this
> document, which is now our proposed candidate first PWD:
> 
>   http://www.w3.org/XML/Group/2009/09/xml-stylesheet.html
>   http://www.w3.org/XML/Group/2009/09/xml-stylesheet.xml
> 
> Comments invited from the WG, before we go fully public.

Given that this is just a second edition of an existing spec,
why is the Abstract text so different?  Why can't the Abstract
text for the 2nd Ed be the same as that in the first?

---

In section 3, under "the following conformance classes", why
is "Documents" a definition, but none of the other are?  I'm
generally confused by the structure of this section.

---

I'm finding the paragraph about user agents very fuzzy and
confusing.  What with xml parsers, a PIPA parser, an 
xml-stylesheet processor, and browser/editor UA's, I have
no idea what "user agent" means and who is supposed to conform 
to what.  I don't have a good suggestion--I'll need to think 
more on this.

---

The only mention of conformance checkers is in the definition
of the conformance checkers conformance class.  I see no point 
in having/mentioning the conformance checkers conformance class
at all.

---

The last sentence of the last entry of section 3 reads 

 Such specifications must not modify the parsing rules defined
 in this specification.

As an editorial suggestion to improve clarity, I'd say:

 Such specifications must not modify the parsing rules defined
 in the _processing instructions with pseudo-attributes_ section
 of this specification.

---

What is marked as the definition of "processing instructions with 
pseudo-attributes" isn't much of a definition.  Even extending
the definition to the rest of the paragraph (as suggested by
Simon) doesn't make it a definition.  This needs to be reworded.

---

In the first para (defn of PIPA) of section 4, the last part
says "user agents must ignore the processing instruction."
See my comment above about user agents--I have a problem with 
this.  In our issue document, we said that a PI that doesn't
match our PIPA syntax is not a PIPA, but we didn't say it
wasn't a PI, so it is not the case that all UAs must ignore it.

---

In [3], the quoting is confusing.  I'm not sure what """ means.
Perhaps it is supposed to be '"'.  Also, some forced line breaks
within that production might make it easier to eye-parse.  I'm
assuming it is supposed to be identical to production [3] in the 
First Ed except for PICharRef in place of CharRef, but it's hard 
to tell.

---

Re:

 There must not be more than one pseudo-attribute with the
 same name in the content of any processing instruction with
 pseudo-attributes. If there are, user agents must ignore the
 processing instruction.

(And the following para also ends with "the processing instruction 
must be ignored".)

As François pointed out, this paragraph is problematic, but mostly
because of my earlier issue with the "user agents" business.  Which
(part of the) user agent ignores what?  We should be saying that
such a PI is no longer considered a PIPA, but it is still a PI,
and who knows what other (part of some) user agent will be interested
in looking at it.  I'm still not sure how to fix this.

---

The first para of section 5 isn't readable.  I suspect "document"
here means "infoset's [document] infoitem", but if so, our decision
to omit the extra infoset-verbiage doesn't work for me.

I also don't think this wording requires that the xml-stylesheet PI 
is in the document entity.  Don't we want to so require?  I don't 
believe many UAs will find/process an xml-stylesheet PI in the
external subset or some other external entity.

---

Under href, the current draft says "The value must match the grammar 
for <IRI-reference>".  Our issues document decision was:

 Nothing will be said in the AssocSS spec about values of the
 href pseudo-attribute.

---

Under type, the current draft says "the value must match the media-type 
token...".  Our issues document decision was:

 For all other pseudo-attributes [other than alternate], the xml-stylesheet
 processor MUST pass the assigned value on to the application.

and, in general, we agreed that nothing will be said in the AssocSS spec 
about values of the type attribute.

---

Under media, the current draft says "the value must be a valid Media 
Query".  Our issues document decision was:

 Nothing will be said in the AssocSS spec about values of the
 media pseudo-attribute.

---

Under chaset, the current draft says "the value must be a valid character 
encoding name...".  Our issues document decision was:

 Nothing will be said in the AssocSS spec about values of the
 charset pseudo-attribute.

---

Re:

 If the value [of the alternate PA] is "yes", it indicates that
 the referenced style sheet is an alternative style sheet, and the
 title pseudo-attribute must also be specified with a non-empty value. 

Who says the title must have a non-empty value?  I don't see that
in the First Edition?

---

Re:

 Other pseudo-attributes must not be specified on xml-stylesheet
 processing instructions. User agents must ignore other pseudo-attributes.

The first sentence isn't actionable--there is no subject for the
"must not", so it doesn't match any of our conformance classes--and 
contradicts the second:  how can a UA ignore something that isn't 
there (and it can't be there if it "must not" be specified).  This
first sentence should be deleted.

---

Re productions [1] and [6], we had said (in the email thread referenced
from issue 15 in our issues document):

 We didn't want to change production [1] because there may be references
 out there to it.  What we are trying to do is add a production for just
 the PI contents that can be referenced by specs that wish to do so without
 invalidating existing references to production [1].

What happened with that idea?

Also, what I see in the draft for productions [1] and [6] doesn't match
http://lists.w3.org/Archives/Public/public-xml-core-wg/2009Jul/0072
which is where I thought we were going.  I think what's in the current
draft is okay, but I'd like to hear the reasons for the differences 
between that email's suggestions and the current draft?

---

Dump the Acknowledgments section

---

paul

Received on Thursday, 17 September 2009 14:58:13 UTC