- From: Michael Kay <mhk@mhk.me.uk>
- Date: Tue, 23 Mar 2004 23:26:21 -0000
- To: <public-qt-comments@w3.org>
I have acted upon these editorial comments as follows:
(see lines annotated "MHK"):
Global Editorial
Different elements exhibit different behaviour with respect to import
precedence. These differences are frequent sources of confusion.
Rationale for the particular behaviour of each element should be provided
in order to aide readers.
MHK: I can't write rationale for something that is irrational. Generally,
I don't think that padding the spec with rationale is a good idea,
especially
in respect of retained 1.0 features.
------------------------------------------------------------------
Section 1.1
The fourth paragraph states that "XSLT is used for a wide range of
XML-to-XML transformation tasks, not exclusively for formatting and
presentation applications."
Although this is introductory, it might be worth noting that it is also
used for a range of XML-to-non-XML transformation tasks as well. For
example, DOM3 test generation.
MHK: DONE. Deleted "XML-to-XML".
------------------------------------------------------------------
Section 2.3
The fifth bullet in the bulleted list refers to the "default mode". This
term should be defined somewhere with a termdef.
MHK: DONE
------------------------------------------------------------------
Section 2.4
The bulleted list of instruction elements should include xsl:param
(probably with "Instructions that declare variables"). If the list isn't
intended to be exhaustive, that should be stated or it should be removed
competely.
MHK: DONE (added xsl:param)
------------------------------------------------------------------
Section 2.5.1
The paragraph that precedes the definition of singleton focus ("Sometimes
the focus is based on a single node.") doesn't flow very well from the
paragraph that precedes it. As it doesn't add anything, it should be
removed.
MHK: DONE (deleted this para)
------------------------------------------------------------------
Section 2.9
In the paragraph before "Example: Errors in Constant Subexpressions", the
scope of the "constant expression evaluation" subphase must be
sufficiently well-defined. A proper specref in place of "XPath
specification states" is required, and should consider making "evaluate"
into a termref.
MHK: I have rewritten this para to include an xspecref to XPath and to use
the identical language that XPath uses.
------------------------------------------------------------------
Section 2.9
The paragraph before "Example: Errors in Constant Subexpressions"
indicates that "any error occurs during [constant subexpression]
evaluation. . . must be held back until the evaluation phase, and
signaled only if the XPath expression is actually evaluated."
It needs to be made clear that if the implementation can determine that
the error would always be reported, that it can do so, as described in the
preceding paragraph. The wording of the last paragraph might be taken to
override the permission provided by the preceding paragraph.
MHK: incorporated in the rewrite as mentioned above.
------------------------------------------------------------------
Section 3.3
In the first paragraph, it needs to be made clear that although the
presence of the extension attribute does not affect the result tree, the
namespace declaration for that extension will affect the result - in
particular, the namespace declaration might be present in the result.
MHK: DONE. Added a note advising use of exlcude-result-prefixes.
------------------------------------------------------------------
Section 3.6
The second paragraph of the note in this section introduces the concept of
"entry modules". Define "entry module" or add a good example. The
meaning isn't necessarily immediately clear.
MHK: DONE. Rephrased the note to avoid introducing this concept.
------------------------------------------------------------------
Section 3.8
The second sentence of the third paragraph contains a link to XPath with
the label "Section". This appears to be a documentation build error of
some sort.
MHK: fixed
------------------------------------------------------------------
Section 4.2
It would probably be helpful to point out to users here the potential
pitfall of using xml:space='preserve' in the presence of xsl:attribute
elements - it might result in a whitespace text node being created as a
child of an element before an attribute node is generated.
MHK: DONE (added a cautionary note)
------------------------------------------------------------------
Section 4.3
The second paragraph reads, "The stripping process takes as input a set of
element names whose child whitespace text nodes are to be preserved." How
that set is constructed is only described further on, beneath the syntax
diagrams for xsl:strip-space and xsl:preserve-space.
That separation makes the quoted sentence seem confusing. One easily
makes the mistake that this is actually referring to the pair of
whitespace-separated lists of NameTests that appear as the values of the
elements attributes in xsl:strip-space and xsl:preserve-space.
MHK: DONE Added a forwards reference to try and clarify the text.
------------------------------------------------------------------
Section 4.4
The title "Attributes Types and DTD Validation" should be "Attribute Types
and DTD Validation" or "Attributes' Types and DTD Validation".
MHK: DONE
------------------------------------------------------------------
Section 4.4
In the second paragraph, it would be helpful to provide a little more
detail about how the equality comparison works.
MHK: DONE. Added an explanation.
------------------------------------------------------------------
Section 5.6.1
The second item in the numbered list, indicates that "Special
considerations apply to two atomic types for which casting to xs:string is
not possible. . . ." However, there is only one such type.
MHK: there is an open issue on these casts. I have added EdNotes to check
the text
against the final outcome on this issue. Affects 5.6.2 also.
------------------------------------------------------------------
Section 6.4
The first item in the numbered list states "First, all matching template
rules that have lower import precedence than the matching template rule or
rules with the highest import precedence are eliminated from
consideration."
The wording of this is ambiguous. It can be read as "First, (all matching
template rules that have lower import precedence than the matching
template rule) or (rules with the highest import precedence) are
eliminated from consideration."
A better wording might be "First, only the matching template rule or rules
with the highest import precedence are considered. Other matching template
rules with lower precedence are eliminated from consideration." The
second item could then be reworded as "Next, of the remaining matching
rules, only those with the highest priority are considered. Other matching
template rules with lower priority are eliminated from consideration."
MHK: DONE. Changed as suggested.
------------------------------------------------------------------
Section 7
In the second paragraph, the use of the term "sorted sequence" is
potentially confusing, as it might refer to a sequence that hasn't been
sorted at all.
We would suggest changing " the input sequence is sorted to produce a
sorted sequence" to "is sorted before being used", and using the term
"input sequence" instead of "sorted sequence" everywhere else.
MHK: I prefer to leave it as it is. I prefer a functional description
to a procedural one. This means the "input sequence" and the "sorted
sequence"
should have different names, and I can't think of any better names.
------------------------------------------------------------------
Section 7
The lead-in to the bulleted list reads "The sequence constructor is
evaluated with the focus set as follows".
This might read better reworded as "For each item in the sorted sequence,
the sequence constructor is evaluated with the focus is set as follows:"
MHK: DONE (rephrased).
------------------------------------------------------------------
Section 9.4
The fourth sentence of the first paragraph uses the term "owned by". This
term is not defined nor is it used anywhere else.
Suggest changing "evaluating the sequence constructor owned by the
variable-binding element" to "evaluating the contents of the
variable-binding elment as a sequence constructor".
MHK: DONE. Changed "owned by" to "contained within".
------------------------------------------------------------------
Section 9.4
In the first sentence of the second paragraph, there is a reference to
Data Model, but it's not clear what one is being directed to see there.
The reference should be placed after the words "The base URI of a node".
MHK: DONE. Used an xspecref.
------------------------------------------------------------------
Section 9.4
In the example "Example: Two-Phase Transformation", it probably will not
be clear to a novice reader that the imported stylesheets in the example
will define templates only for the particular modes.
MHK: DONE. Explanation added.
------------------------------------------------------------------
Section 9.4
The note suggests it is a good idea to use modes when transforming
temporary trees. It should be clarified that that's only necessary if
different templates actually need to be applied.
MHK: DONE.
------------------------------------------------------------------
Section 10.1.2
In the xsl:number instruction in "Example: Using Tunnel Parameters",
'format="{$format}"' should be 'format="{$equation-format}"'.
MHK: corrected previously.
------------------------------------------------------------------
Section 10.3
It is easy for a reader to make the mistake that the override attribute
can be used to prevent a stylesheet function from overriding another
stylesheet function with the same expanded QName with lower import
precedence. It should be made very clear that it can only override
"built-in" functions. That could include renaming the attribute to
something like "override-builtin-functions". An example illustrating the
behaviour would also be appropriate.
MHK: DONE. I have added a note to guard against this misreading of the spec.
------------------------------------------------------------------
Section 10.3
The bulleted list describing which stylesheet functions are included in
the in-scope functions is somewhat confusing.
It would probably be easier to read if reworded to describe the intended
effect - for example, "A stylesheet function definition suppresses any
other stylesheet function defintions with the same name and arity that has
lower import precedence. It is added to the in-scope functions, unless
the override attribute has the value "no" and there is a
processor-provided function of the same name and arity, in which case that
function will be included in the in-scope functions."
MHK: I have experimented with other ways of expressing this rather complex
set of conditions and have not found a way of doing that is clearer than the
current rules. I proposed to leave it as is.
------------------------------------------------------------------
Section 10.3
In the second note, which describes the override attribute, it might not
be clear that the attribute can override extension functions that might be
provided by the user, not just functions that are provided by the
implementation.
MHK: DONE.
------------------------------------------------------------------
Section 11.1.2
The fifth sentence of the third note states, "One consequence of this is
that these attributes should not be written as attribute value templates:
although an XSLT processor will understand this notation, the XML parser
will not."
Making a normative statement with the RFC term "should not" isn't
appropriate in a note. Either this needs to be stated normatively or use
of the RFC "should not" should be avoided.
MHK: DONE. Rewritten using "it is inadvisable..."
------------------------------------------------------------------
Section 11.1.2
The third paragraph of the third note states "None of these attributes
will be generated in the result tree unless the stylesheet writes them to
the result tree explicitly, in the same way as any other attribute."
It might not be clear to a user why he or she might have thought these
attributes would have been generated automatically. It might be helpful
to describe the fallacious reasoning that this sentence is trying to
correct.
MHK: No action. Sorry, but I'm not good at writing fallacious logic.
------------------------------------------------------------------
Section 11.1.2
Error XT0805 is "It is a static error if an attribute on a literal result
element is in the XSLT namespace, unless it is one of the attributes
explicitly defined in this specification."
It would be helpful to point out to readers that they might need to use
namespace aliasing or xsl:element/xsl:attribute if they really need to
create such attributes in the XSLT namespace.
MHK: DONE (added a note)
------------------------------------------------------------------
Section 11.1.3
It is odd that a feature like exclude-result-prefixes is defined here,
rather than in its own section. It might be better as a subsection in the
Namespace fixup section.
MHK: No change. The reason it is here is to emphasize that ERP applies only
to namespaces generated while processing a literal result element.
------------------------------------------------------------------
Section 11.1.3
A sentence in the third bullet states "It is a static error if there is no
namespace bound to the prefix on the element bearing the
[xsl:]exclude-result-prefixes attribute."
The words "prefix on the element" make it sound like this is talking about
the prefix of the element. We suggest changing "on the element" to "by
the element".
MHK: DONE. Rephrased, and added an error code XT0808.
------------------------------------------------------------------
Section 11.1.3
The third bullet makes reference the "The default namespace (as declared
by xmlns)". It might be unclear to some readers whether default namespace
refers to a namespace declared using xmlns="uri" or the default - no
namespace. It would be worthwhile defining the term in one place, and
including termref's to it.
This same comment applies to the second paragraph after the first bulleted
list in 11.1.4, and in the paragraph in Section 11.2 that defines error
XT0830.
MHK: I will add a reference to section 6.2 of the Data Model for the
definition of "default namespace".
MHK: There also seems to be a missing error condition for the case where
#default is used (in 11.1.3) when there
is no default namespace. I have allocated error 0809. (Making this an error
is consistent with the treatment
of #default in xsl:namespace-alias).
------------------------------------------------------------------
Section 11.1.3
The last paragraph of the example "Example: Excluding Namespaces from the
Result Tree" begins "If the stylesheet is changed so that the literal
result element has an attribute b:bar="3", then the element in the result
tree will typically have a namespace declaration xmlns:b="b.uri", although
the processor is free to choose a different namespace prefix if it
wishes."
This should be reworded to indicate that some namespace declaration for
the namespace must be available, rather than appealing to the typical
behaviour.
MHK: No change, This is only an example, so I prefer to make it a concrete
example
of how a real processor might behave, not a generalized description of all
the possibile behaviors.
------------------------------------------------------------------
Section 11.1.3
The material that appears in the last paragraph of the example "Example:
Excluding Namespaces from the Result Tree" would be better placed in
Section 5.6.3.
MHK: No change. The material belongs with the example that precedes it.
------------------------------------------------------------------
Section 11.1.4
The second note in this section states, "The processor still has a free
choice of prefixes when generating element and attribute names in the
result tree, but it will normally use the result-prefix since that prefix
will already be declared in the result tree."
As this is implementation dependent, the note shouldn't refer to the
"normal" behaviour. If we want to make a normative statement, that can't
be handled editorially.
MHK: Actually, the choice of prefix is quite constrained, under the
namespace fixup
rules. I have deleted the quoted sentence.
------------------------------------------------------------------
Section 11.1.4
In the example box, the paragraph before the second stylesheet states in
part, "however, the rules guarantee that there will be a namespace node
that binds the prefix xsl to the URI http://www.w3.org/1999/XSL/Transform,
which makes it safe to use the QName xsl:version in the content of the
generated stylesheet."
It might not be clear to the reader which rules guarantee this. That
should be explicitly stated.
MHK: It's the combination of all the rules. I don't think it would help to
restate them: the reader is just going to have to work through all the rules
to
confirm that they do indeed give the answer as shown. We're not going to
make
namespace-alias easy to understand, however hard we try.
------------------------------------------------------------------
Section 11.1.4
It might be worthwhile to add a note that describes the merits of using
xsl:attribute and xsl:element over using namespace aliasing. For example,
"xsl:element and xsl:attribute (see following sections) can also be
practical solutions for the tasks commonly addressed via namespace
aliasing. They have the advantages of being more direct and of permitting
more explicit "hinting" about the desired prefix, at the expense of being
more verbose. Users may wish to consider both approaches and select the
one which best suits their needs."
MHK: I have added a note along these lines, suggesting the alternative
approach but without discussing its relative merits.
------------------------------------------------------------------
Section 11.2
In the description of the recovery action for Error XT0820, it might be
worthwhile to add that the xsl:element is replaced by its children, in
case the effect of the recovery isn't clear to all readers.
MHK: I have raised a separate comment (review of dynamic errors) which
would remove this recovery action.
------------------------------------------------------------------
Section 11.2
The recovery action for Error XT0820 is potentially surprising. Some
rationale for the recovery action might be appropriate.
MHK: I have raised a separate comment (review of dynamic errors) which
would remove this recovery action.
------------------------------------------------------------------
Section 11.2
The recovery action for XT0830 is "to ignore the prefix part of the
lexical QName, with the effect that the new element will be in the default
namespace." It is not clear whether the element is in the default
namespace of the result or the default namespace of the stylesheet.
MHK: changed this to read: "...with the effect that the
name of the new element will be in the default namespace
of the xsl:element instruction if the instruction has a default namespace,
and will be
in no namespace if it does not."
------------------------------------------------------------------
Section 11.3
Error XT0840 states "It is a static error if the select attribute of the
xsl:attribute element is present unless the element has empty content."
Section 5.6 deals with stripping of whitespace nodes in this situation,
but it might make things more clear to say "unless the element has empty
content after whitespace nodes have been stripped from the stylesheet."
MHK: I think there are many places where we would need to make such changes.
The
point of pulling the whitespace stripping into one place is that we only
need
to say it once. No change.
------------------------------------------------------------------
Section 11.4.2
In the second paragraph, the phrase "either a single node, the newly
constructed text node, or an empty sequence" might be taken to present
three choices rather than two. It should be rephrased as "either the
newly constructed text node or an empty sequence."
MHK: DONE.
------------------------------------------------------------------
Sections 11.4.2 and 11.4.3
These sections should state that the text created by xsl:text or
xsl:value-of instructions might be merged with other adjacent text into a
single text node. This is only stated explicitly in the case of literal
text nodes in 11.4.1.
MHK: DONE. The note has been moved up a level, to 11.4, and expanded.
------------------------------------------------------------------
Section 11.5
The note begins "This means that xsl:processing-instruction cannot be used
to output an XML declaration." It is not clear what the antecedent of
"this" is. Is it the rule in XT0890 or the fact that xsl:attribute cannot
be used to construct the pseudo-attributes of a processing instruction?
MHK: DONE (clarified)
------------------------------------------------------------------
Section 11.6
The sections on xsl:element and xsl:attribute state "The effective value
[of the namespace attribute] should be a URI reference. It is not an
error if the string is not a syntactically legal URI reference." A
similar statement is required for xsl:namespace.
MHK: DONE
------------------------------------------------------------------
Section 11.6
The second paragraph of the first note in this section states that adding
a namespace node to the result tree "does, however, constrain the choice
of prefixes when namespace fixup is performed."
The word "does" should be changed to "might" - adding such a namespace
node could also increase the number of choices available or have no effect
on the choice.
MHK: DONE
------------------------------------------------------------------
Section 11.8.1
The second note states "but if namespaces are used in the content of the
attribute. . . then it is the responsibility of the stylesheet author to
ensure that suitable namespace declarations are added to the result tree."
This should really begin "but if namespace prefixes are used. . . ." A
namespace URI could be used inside of an attribute without requiring any
namespace declaration.
MHK: DONE
------------------------------------------------------------------
Section 13.1.2
The second paragraph uses the term "converted" twice. This should be
"cast" to avoid any confusion about the meaning of the term.
MHK: No. The following sentence explains that conversion is done using the
string() or number() function, it is not done using the casting rules.
------------------------------------------------------------------
Section 13.1.3
The paragraph after the second note indicates that the lang and case-order
attributes "identify a suitable collation". It should be noted that for
any particular combination of lang and case-order, there may be more than
one suitable collation.
MHK: I've changed "identify" to "locate". (I hate the word "locate",
because it really means "to place in a location", not "to find". But I think
it's OK here).
------------------------------------------------------------------
Section 14.3
The last sentence in the second paragraph states that "A group is never
empty." The fifth paragraph begins with the sentence "If the population
is empty, the number of groups will be zero." These two related sentences
should probably appear closer to one another.
MHK: DONE
------------------------------------------------------------------
Section 14.3
In the definition following XT1090, there is no term that is in bold type
that is being defined. Is this defining "grouping key"?
MHK: DONE (improved the definition)
------------------------------------------------------------------
Section 14.3
The definition of "processing order" ends prematurely. To complete the
definition, the two sentences that follow should probably be included in
the definition. Otherwise, the definition should be reworded in order to
stand alone.
MHK: DONE (improved the definition)
------------------------------------------------------------------
Section 14.3
The title of the example box "Example: Sorting Groups in order of their
Grouping Key" isn't accurate - it includes two examples, only one of which
uses a grouping key.
MHK: DONE (changed the title)
------------------------------------------------------------------
Section 15.1
The paragraph following XT1150 begins "The xsl:analyze-string instruction
starts at the beginning of the input string and attempts to find the first
substring that matches the regular expression."
It doesn't seem appropriate to talk about this particular complexity of
regular expression matching, out of all the other complexities discussed
in the F&O. A reference to F&O would probably be more appropriate.
MHK: This would be fair comment if there were a common description that
replace(),
tokenize(), and analyze-string could all refer to. But there isn't. No
change.
------------------------------------------------------------------
Section 15.2
In the definition of "current captured substrings", "parenthized" should
be "parenthesized".
MHK: DONE
------------------------------------------------------------------
Section 15.2
The behaviour of the regex-group function is not sufficiently specified
when it is used within xsl:non-matching-substring and outside of
xsl:analyze-string - in particular, how is an argument value of zero
handled in those situations? It's not clear whether the matching string
is considered to be considered to be a one of the current captured
substrings, and so, part of the sequence, which would imply that
regex-group(0) should return the zero-length string in those situations,
or whether it is still "the same as the value of . (dot)" in those
situations.
MHK: Good point (it's really a technical point rather than editorial).
I have clarified it.
------------------------------------------------------------------
Section 16.1
The last rule in this section begins "The effect of these rules. . . ."
These rules have more than one effect; this should be "One effect of these
rules. . . ."
MHK: DONE
------------------------------------------------------------------
Section 16.2
The second paragraph indicates that "The URI must contain no fragment
identifier. . . ." Presumably this is because the text has no known
structure. It would be helpful to state the rationale behind the
restriction.
MHK: we could support fragment identifiers for specific media types
such as HTML, I think the rationale is to reduce the burden on the
implementation. On the whole, I prefer to avoid including rationale
for this kind of thing: the spec is not required to justify itself.
------------------------------------------------------------------
Section 16.2
The paragraph following the first note, states "This encoding is used to
translate the contents of the file into a string." More accurately, it
specifies a default unless file-specific information is available as
described further on.
MHK: I have deleted the offending sentence.
------------------------------------------------------------------
Section 16.3.2
The paragraph following the bulleted list describes the interpretation of
the current function when it appears in match or use in xsl:key. This
really belongs in 16.3.1 - though the wording might be complicated by the
fact that it can't refer to the node N that is being considered.
MHK: I have deleted the paragraph. It is already covered by the rules for
the
current() function in 16.6.1.
------------------------------------------------------------------
Section 16.5.2
The seventh paragraph reads as follows:
<<
The choice of the names and abbreviations used in any given language is
implementation-defined. For example, one implementation might abbreviate
July as Jul while another uses Jly. In German, one implementation might
represent Saturday as Samstag while another uses Sonnabend.
Implementations may provide mechanisms allowing users to control such
choices.
>>
It should be explicitly stated that mechanisms that allow users to control
such choices must not be in the form of additional, implementation-defined
presentation modifiers.
MHK: I don't think this is true. The set of presentation modifiers is
defined
by reference to format tokens allowed by xsl:number, and xsl:number
explicitly
allows additional implementation-defined format tokens.
------------------------------------------------------------------
Section 16.6.5
The sentences before and after the note in this section are related, and
should probably be placed in a single paragraph, rather than being
separated by a note.
MHK: DONE
------------------------------------------------------------------
Section 18.1
The first paragraph of this section needs to deal with the fact that the
stylesheet function with highest import precedence might have specified
the override attribute with a value of "no". We understand that the
reference would be to the extension function in this case.
MHK: Yes. It also needs to handle the case where it is a constructor
function for a user-defined (or built-in) atomic type, or where the
prefix identifies the fn: namespace. Reworded.
------------------------------------------------------------------
Section 18.2.2
The first paragraph states, "The element-available function can be used
with the xsl:choose and xsl:if instructions to explicitly control how a
stylesheet behaves if a particular extension instruction is not
available."
The element-available function applies to instructions in the XSLT
namespace as well as to extension instructions. The quoted sentence needs
to be reworded.
Given that the function applies to more than just extension instructions,
perhaps it should be moved to another section.
MHK: I will leave it where it is, but emphasize that it also tests
availability of XSLT instructions.
------------------------------------------------------------------
Section 19
In the second paragraph, suggest changing "may be created" to "can be
created", to avoid confusion with the RFC term.
MHK: DONE
------------------------------------------------------------------
Section 19
The fourth paragraph begins "A result tree has a URI." We would suggest
this be changed to "A result tree is assigned a URI when it is created" or
perhaps "A result tree is assigned an absolute URI when it is created."
MHK: DONE
------------------------------------------------------------------
Section 19
The first note begins "The URI of the result tree is not the same thing as
the URI of its serialized representation. . . ." The words "is not the
same thing" are too strong; perhaps, it should be "is not necessarily the
same thing"
MHK: DONE
------------------------------------------------------------------
Section 19
The last sentence of the first note begins "As long as it satisfies
requests. . . ." It is not clear what the antecedent of "it" is in this
case. Perhaps this should be "As long as the API satisfies requests. . .
."
MHK: Changed to "the processor"
------------------------------------------------------------------
Section 19
All this description of how the URI that is associated with the result
tree might be utilized by an API seems like it belongs with the
description of the href attribute in section 19.1, as it specifies the
URI.
MHK. Yes. text moved.
------------------------------------------------------------------
Section 19
In the last note, the phrase "is unrelated" is too strong. We would
suggest "may differ from"
MHK: DONE
------------------------------------------------------------------
Section 19.1
The fourth paragraph following XT1460 states that "An implementation that
does not support the serialization of result trees. . . must provide the
application with some means of access to the (un-serialized) result tree,
optionally using its URI to identify it." However, the fourth paragraph
of Section 19 states that "If the implementation provides an API to access
result trees, then it must allow a final result tree to be identified by
means of this URI."
The two statements differ as to whether an API must allow result trees to
be identified by URI.
MHK: deleted "optionally".
------------------------------------------------------------------
Section 19.2
A brief summary of the distinction between the validity and type
attributes -- validity tests for any valid type, while type insists on
validating against a specified type, if I'm reading this correctly --
would tremendously improve readability of this section, by setting context
and giving the reader some guidance as to the differences in syntax and
semantics.
MHK: DONE
------------------------------------------------------------------
Section 19.2.1
The first and second subbullets of the third bullet in the first bulleted
list indicate that in certains circumstances the "transformation fails."
It would be helpful to provide a link to the error that is reported in
each case, because the definitions of the definitions of those errors are
so far-removed.
MHK: DONE
------------------------------------------------------------------
Section 19.2.1
The third subbullet of the the third bullet in the first bulleted list
states that "The schema components used to validate an element or
attribute may be located in any way permitted by [XML Schema]." The word
"permitted" is too strong; the section of XML Schema that is cited just
describes a number of possibilities, without any restrictions. Perhaps
"described" would be a better word.
MHK: done.
Where the remainder of the bullet indicates that the processor might have
implicit knowledge of a namespace or may use a schemaLocation to locate
schema components, it should be made clear that those are just two
possibilities - not an exhaustive list.
MHK: done
------------------------------------------------------------------
Section 19.2.1
The third bullet of the second bulleted list states, "If the element or
attribute is not considered valid, the transformation fails." For
clarity, the word "valid" should be changed to "a valid instance of the
specified type".
MHK: after "considered valid" I have added "as defined above".
------------------------------------------------------------------
Section 19.2.1
The first part of this section is specific to [xsl:]validation; the second
part is specific to [xsl:]type. It is not clear whether the paragraphs
and bulleted lists following the last note in this section only apply if
the [xsl:]type attribute is specified.
MHK: I have added some level-4 headings to make things clearer.
------------------------------------------------------------------
Section 20
The paragraph following XT1560 states that "The values of attributes are
defaulted after the xsl:output elements have been merged. . . ." However,
if no method attribute is specified, not all of the default attribute
values are necessarily known after merging.
MHK: I have rewritten the paragraph.
------------------------------------------------------------------
Section 20
The third bullet from the end of the list states, "The
undeclare-namespaces attribute is relevant only when producing output with
method="xml" and version="1.1"." This should probably be rephrased to
allow for future versions of XML.
MHK: done
------------------------------------------------------------------
Section 21
The note in this section refers to the static typing feature. Some
normative statement about this feature should be provided - perhaps in
section 2.8
MHK: the note says that there is no static typing feature. There is no need
to say that normatively.
------------------------------------------------------------------
Section 21.1
The second note indicates that a processor might ignore non-trivial type
annotations from PSVI in order to construct a data model that conforms to
the requirements of a basic XSLT processor. It should also be noted that
the data model cannot be constructed from Infoset as described in the Data
Model document, as that can result in attributes with types that aren't
permitted for a basic XSLT processor - such types would similarly have to
suppressed in order to construct a data model that conforms to the
requirements of a basic XSLT processor.
MHK: I've extended the note.
------------------------------------------------------------------
Appendix F
Whether a processor supports the XML 1.0 or 1.1 definitions of the Char
and NCName productions should be an implementation-defined feature.
Section 4.1 does not currently describe this as implementation-defined,
but it ought to.
MHK: done.
------------------------------------------------------------------
Appendix F
Items 20 and 23 in this list appear to be subsets of the
implementation-defined feature in item 21.
MHK: I have consolidated the list.
------------------------------------------------------------------
Received on Tuesday, 23 March 2004 18:27:30 UTC