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?


> 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?


> -----
>
> 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?

"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.


> 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?
>
> -----
>
> 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.


> 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.


> -----
>
> 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.


> -----
>
> 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?


Thanks for the comments,
-- 
Simon Pieters
Opera Software

Received on Thursday, 12 November 2009 09:59:14 UTC