RE: Comments on AssocSS Editor's Draft 10 November 2009

It's looking pretty good to me.  Some comments embedded.
If I haven't made a comment about something, I'm fine
with how it is.

> -----Original Message-----
> From: Simon Pieters [mailto:simonp@opera.com]
> Sent: Thursday, 2009 November 12 3:59
> To: Grosso, Paul; public-xml-core-wg@w3.org
> Subject: Re: Comments on AssocSS Editor's Draft 10 November 2009
> 
> On Wed, 11 Nov 2009 22:24:28 +0100, Grosso, Paul <pgrosso@ptc.com>
> wrote:
> 
> >
> >> -----Original Message-----
> >> From: Simon Pieters [mailto:simonp@opera.com]
> >
> >> http://www.w3.org/XML/Group/2009/09/xml-stylesheet.html

> >
> >
> > 3 Conformance requirements section:
> >
> > I think this latest draft is an improvement in this area,
> > but there seems to be something missing here.  In the
> > intro, we mention "Conformant user agents" [is the proper
> > term "conformant" or "conforming"?] but we don't define
> > that in section 3.
> 
> Removed "Conformant" in the intro.
> 
> 
> > Also, we talk in terms of conformance
> > criteria for authors, but what is a conforming author?
> 
> One that follows the requirements. :-)
> 
> 
> > I think we should talk in terms of conformance of
> > documents and conformance of processors (UAs) as we
> > do in the namespace spec for example.  (In XML specs,
> > we generally talk of processors, not user agents, so
> > I would prefer to use that terminology.)
> 
> Ok. Changed.
> 
> 
> > Then I think we should add to section 3 some statements
> > that define conformance of documents and conformance of
> > processors--again, see the NS 1.0 3rd Ed PER at
> > http://www.w3.org/TR/2009/PER-xml-names-20090806/

> > for inspiration.
> 
> Do you have any suggestions for what it should say?

Replace the Note you just added with the following (with
appropriate markup and links):

 Documents conforming to this specification MUST be well-formed
 XML documents that conform to all the MUST and MUST NOT constraints
 given for documents in this specification.

 Processors conforming to this specification MUST conform to all
 the MUST and MUST NOT constraints given for processors in this
 specification.  Processors do not have to check or enforce any
 of the constraints given for documents in this specification.

> 
> > In particular, we need to make it clear
> > that a conforming processor does not have to check/enforce
> > any of the constraints on documents, just the constraints
> > on processors.
> 
> Added a note.
> 
> 
> > Then throughout the document, when we talk of "authors
> > must", change that do talk about documents instead of
> > authors.
> >
> > -----
> >
> > 4 Pseudo-attributes, first para:
> >
> > Don't use "returned" here.  Rather, the second sentence
> > should read something like:
> >
> >  The result of such parsing is either a set of pseudo-attributes
> >  or an error.
> >
> > and just delete the third sentence.  (Note, I changed "list"
> > to "set" because "list" usually implies order, and a set of
> > attribute specifications is unordered.)
> 
> Done.
> 
> 
> > -----
> >
> > 4 Pseudo-attributes, second para:
> >
> > I don't think the first sentence is necessary, and I don't
> > like the "return" wording in the second.  I'd suggest instead
> > for this para:
> >
> >  If the given string is not completely matched by grammar
> >  given by the following productions, the parsing results
> >  in an error.
> 
> I changed it to "If the given string is not matched by the PseudoAtts
> production, the parsing results in an error.". Is that ok?

Yes.

> 
> 
> > -----
> >
> > 4 Pseudo-attributes section, "symbol" and "above" wording:
> >
> > Throughout, we use the word "symbol" where I would expect the
> > word "token" or--as seems to be done in most other specs--nothing.
> > That is, instead of "Each string matched by the PseudoAtt symbol"
> > we should instead say "Each string matched by PseudoAtt" where,
> > of course, the word PseudoAtt is linked as it is now.
> >
> > Where we say things like "in the PseudoAtt production", I think
> > that wording is fine, but I'd delete the word "above" throughout
> > this section--the link takes you to the right place, and we don't
> > need positional words that might become invalid if we reordered
> > things someday or if "above" is wrong for certain media or
> > certain translations.
> 
> Done.
> 
> Is the following paragraph ok? Should it say tokens instead of symbols?

Moot, since you accepted my suggested rewording below that
avoids the issue.

> 
> "The productions in this specification use the same notation as used in
> the XML specification [XML]. Symbols in the grammar that are not
> defined
> in this specification are defined in the XML specification."
> 
> 
> > -----
> >
> > 4 Pseudo-attributes, the productions:
> >
> > In the 1st Ed, we have the - (Char* '?>' Char*) construct
> > on the PseudoAttValue production whereas in the 2nd Ed we
> > have it on the StyleSheetPI production.  I suspect Simon
> > did this so that the rules for parsing pseudo-attributes
> > from a string could be used elsewhere than in PIs.
> >
> > I don't think '?>' is allowed by the grammar anywhere other
> > than within PseudoAttValue, so I think this change is equivalent
> > for our purposes, but I wanted to raise the question to make
> > sure we're all okay with this.
> >
> > -----
> >
> > 4 Pseudo-attributes, paras following the productions:
> >
> > Since the third para following the production defines the
> > value of the pseudo-attribute, I think the paras about
> > charref replacement belong here.  I also want to avoid
> > the "return an error" and "return a list" wording.  Here
> > is my suggested rewording of the part of section 4 following
> > the productions that also implements my previous "symbol"
> > and "above" wording comment--I don't show links and other
> > markup which should be retained from the current draft
> > (except for the "Legal Character" issue I mention later):
> >
> >  [Definition: Each string matched by PseudoAtt represents
> >  a pseudo-attribute.] A pseudo-attribute has a name and
> >  a value.
> >
> >  [Definition: The string matched by Name in the PseudoAtt
> >  production constitutes the name of the corresponding
> >  pseudo-attribute.]
> >
> >  [Definition: The string matched by PseudoAttValue in the
> >  PseudoAtt production--after any CharRefs and PredefEntityRefs
> >  are replaced with the characters they represent--constitutes
> >  the value of the corresponding pseudo-attribute.]  Each
> >  CharRef in PseudoAttValue is replaced with the character it
> >  represents according to XML. [XML]  Each PredefEntityRef in
> >  PseudoAttValue is replaced with U+0026 (&) if it is "&amp;",
> >  U+003C (<) if it is "&lt;", U+003E (>) if it is "&gt;",
> >  U+0022 (") if it is "&quot;", and U+0027 (') if it is "&apos;".
> >
> >  This parsing results in an error if the XML Legal Character
> >  well-formedness contraint is violated for any CharRef.
> >
> >  This parsing results in an error if there is more than one
> >  pseudo-attribute with the same name.
> >
> > Note that I have deleted what was the final paragraph.
> >
> > Note that I changed "in the pseudo-attribute's value" to
> > "in PseudoAttValue" when talking about replacing charrefs
> > because the charrefs are in PseudoAttValue, not in the
> > (resulting) pseudo-attribute's value.
> >
> > Also, in the current draft, "Legal Character" has a link
> > to #wf-Legalchar which does not exist.  It should be a link
> > to http://www.w3.org/TR/XML/#wf-Legalchar, and I think the
> > entire phrase "Legal Character well-formedness contraint"
> > should be within the link.
> 
> Implemented these suggestions.
> 
> 
> > -----
> >
> > 5 The xml-stylesheet processing instruction, first 2 paras:
> >
> > I'm okay with the technical content, but I'd suggest some
> > rewording.  In particular, I want to avoid procedural
> > language like "return", we should talk about stylesheet
> > association rather than linking, we should talk of document
> > conformance rather than authors, and I'm trying to make
> > things a bit easier to understand (though I realize that
> > is subjective).  Here is my suggestion:
> >
> >  For any processing instruction for which all of the
> >  following are true:
> >
> >  * the processing instruction information item is in the
> >    [children] property of the document information item
> >
> >  * the processing instruction information item appears
> >    before the element information item of the document
> >    information item's [children] property
> >
> >  * the processing instruction information item has the
> >    [target] property xml-stylesheet
> >
> >  a processor conforming to this specification MUST use
> >  the rules for parsing pseudo-attributes from a string,
> >  using the processing instruction information item's
> >  [content] property as the string.
> >
> >  [Definition: Any such processing instruction for which
> >  the rules for parsing pseudo-attributes from a string
> >  do not result in an error is said to be an xml-stylesheet
> >  processing instruction.]
> >
> >  Documents conforming to this specification MUST NOT
> >  use processing instruction information items with the
> >  [target] property xml-stylesheet if they are not
> >  xml-stylesheet processing instructions.
> 
> Changed to be more like the above.

I'm okay with your changes except delete the ellipsis (the ...).

> 
> 
> > There is nothing in this section that says that
> > processors (user agents) need to do anything with an
> > xml-stylesheet PI.  Should there be?
> 
> I've required the error or set of pseudo-attributes to be passed to the
> application.
> 
> 
> > The first edition of AssocSS says:
> >
> >  The xml-stylesheet processing instruction is allowed only
> >  in the prolog of an XML document. The syntax of XML
> >  constrains where processing instructions are allowed in
> >  the prolog; the xml-stylesheet processing instruction is
> >  allowed anywhere in the prolog that meets these constraints.
> >
> > Our draft 2nd Edition is more restrictive in that we don't
> > consider PIs within the (internal or external subset of the)
> > document type declaration.  We are therefore making some
> > documents conforming to AssocSS 1st Edition non-conforming
> > to the 2nd Edition.  Henry, are you okay with this?

We probably need to discuss this on our next call.

> >
> > -----
> >
> > 5 The xml-stylesheet processing instruction, the pseudo-atts:
> >
> > My understanding of our earlier discussions was that we weren't
> > going to say anything about values for these pseudo-attributes.
> >
> > I realize that Simon has written all the constraints as constraints
> > on the document, not the processor, so I can live with that if that's
> > the decision of the WG, but that isn't what we had decided, and we
> > haven't discussed the specifics of the constraints (because we had
> > decided not to put any into the spec).
> >
> > So I'm going to ask for a WG vote on whether we now agree to have
> > all these constraints or not, and if we do agree, then we have to
> > agree on the specifics of what they say.
> >
> > If we leave the constraints, we need to change "author" to
> "document".
> >
> > We also need to decide if the document constraints should be MUSTs.
> > Since there were no such constraints in the 1st Edition,
> 
> Actually, there were, by referencing HTML4 for requirements about href,
> media, etc.

But HTML4 did not, for example, require that values of the media
attribute matches the media_query_list production of the Media 
Queries specification because that spec didn't yet exist.  So 
by putting MUSTs in here, I still believe we are making some documents 
conforming to AssocSS 1st Edition non-conforming to the 2nd Edition.

> 
> 
> > MUSTs
> > would make some documents conforming to AssocSS 1st Edition
> > non-conforming to the 2nd Edition.
> >
> > In AssocSS 1st Edition, there is the following note:
> >
> >  NOTE: Since the value of the href attribute is a URI reference,
> >  it may be a relative URI and it may contain a fragment identifier.
> >  In particular the URI reference may contain only a fragment
> >  identifier. Such a URI reference is a reference to a part of
> >  the document containing the xml-stylesheet processing instruction
> >  (see [RFC2396]). The consequence is that the xml-stylesheet
> >  processing instruction allows style sheets to be embedded in
> >  the same document as the xml-stylesheet processing instruction.
> >
> > Do we want to leave it or some version of it in the 2nd Ed?
> 
> I'll punt on it for now. I think it's more effective for style sheet
> languages that allow this to describe how it works.

I can live with that, but I'd like to hear from others in the WG.

> 
> 
> > -----
> >
> > 5 The xml-stylesheet processing instruction, the penultimate para:
> >
> > I'd reword, and I think I'd prefer to break it into two paras:
> >
> >  A document conforming to this specification must not specify
> >  other pseudo-attributes on xml-stylesheet processing instructions.
> >
> >  Processors conforming to this specification must ignore other
> >  pseudo-attributes on xml-stylesheet processing instructions.
> 
> Broken into two paragraphs. I like the current wording better; in
> particluar I don't like the construction "Foo conforming to this
> specification must X" because that makes it sound like a statement of
> fact, or that it would be fine to not conform to the specification,
> while "Foo must X" is more of a direct requirement.

[And then you removed the second para per a follow up email,
and I'm fine with the result.]

> 
> 
> > -----
> >
> > 5 The xml-stylesheet processing instruction, the last para:
> >
> > s/before the links specified by/before the association specified by/
> 
> Changed to "associations".
> 
> 
> > -----
> >
> > References.
> >
> > s/Referneces/References/
> 
> Fixed.
> 
> 
> > -----
> >
> > Acknowledgements.
> >
> > I will continue to request that we delete this entire section.
> 
> Why?

Because I think everyone who contributes to a W3C spec--not counting
the editors--deserves equal credit, so I don't like naming some but
not others.  And I've seen specs with acknowledgements that include 
people that contributed to such an early version that it's almost 
silly to still have their name associated with it (viz. NS 1.0), 
and I don't like to continue such a trend.  Finally we all contribute 
to the progress of W3C on a voluntary basis, and I don't think that 
we should do that with the expectation of seeing our name in print. 

I guess I'm just against acknowledgements.  But this is my opinion
as a WG member, not the chair, so we'll see what others say.

paul

Received on Thursday, 12 November 2009 20:15:51 UTC