- From: Grosso, Paul <pgrosso@ptc.com>
- Date: Wed, 11 Nov 2009 16:24:28 -0500
- To: <public-xml-core-wg@w3.org>
> -----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. Also, we talk in terms of conformance
criteria for authors, but what is a conforming author?
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.)
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. 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.
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.)
-----
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.
-----
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.
-----
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 "&",
U+003C (<) if it is "<", U+003E (>) if it is ">",
U+0022 (") if it is """, and U+0027 (') if it is "'".
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.
-----
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.
There is nothing in this section that says that
processors (user agents) need to do anything with an
xml-stylesheet PI. Should there be?
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, 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?
-----
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.
-----
5 The xml-stylesheet processing instruction, the last para:
s/before the links specified by/before the association specified by/
-----
References.
s/Referneces/References/
-----
Acknowledgements.
I will continue to request that we delete this entire section.
=====
paul
Received on Wednesday, 11 November 2009 21:26:10 UTC