This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 2422 - unclear how to interpret empty attribute values in xsl:output declarations
Summary: unclear how to interpret empty attribute values in xsl:output declarations
Status: CLOSED INVALID
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 2.0 (show other bugs)
Version: Working drafts
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-28 00:50 UTC by Mike Brown
Modified: 2007-02-25 23:57 UTC (History)
0 users

See Also:


Attachments

Description Mike Brown 2005-10-28 00:50:48 UTC
It is not clear in XSLT 2.0 (or 1.0) how a processor should handle empty
attribute values in xsl:output declarations. Is this something that could be
addressed in XSLT 2.0?

Basically, we have a case where a user wants to be able to have an importing
stylesheet suppress the generation of a DOCTYPE. Is this possible?

For example, what does doctype-system="" mean? Is it supplying an 'explicit'
value for doctype-system? What should the effect of such a declaration be, if it
is in an importing stylesheet, while doctype-system="foo" is in the imported
stylesheet? Should the processor use "foo" or "" or should it 'undeclare' the
doctype-system altogether and thus use a default value (unless there's another
value with a higher import precedence)?

How would other xsl:output attributes be affected by empty values? For example,
cdata-section-elements="" in the importing stylesheet, and
cdata-section-elements="x y z" in the imported stylesheet. Would the result be
as if there were one declaration, "x y z", or would it be as if there were no
declaration? What if that first stylesheet were imported by a stylesheet
containing cdata-section-elements="w x y"? Would the result be "w x y z" or "w x y"?

Thanks
Comment 1 Michael Kay 2005-10-28 18:31:13 UTC
It seems to me that the spec is pretty clear on what the permitted values of
each of the xsl:output attributes are. For example, the indent attribute must be
"yes" or "no" and an empty string is therefore an error. On the other hand,
doctype-public is simply a "string" and therefore the empty string is a
permitted value (although not a very useful one). For cdata-section-elements the
value is a list of QNames, and an empty list of QNames is perfectly well-defined.

Michael Kay (personal response)
Comment 2 Mike Brown 2005-10-28 20:56:42 UTC
I am not asking what an empty string as the attribute value in isolation means.
I am asking about the interaction of explicit empty-string attribute values, in
attributes that allow such values, across import precedences. I think anything
else I could say to clarify would just be repeating the original inquiry. Does
doctype-system="" override a lower-precedence doctype-system="foo"? (My
colleagues and I think it should.) Does cdata-section-elements="" override a
lower-precedence cdata-section-elements="x y z"? (My colleagues and I think it
shouldn't, but but maybe it should?)
Comment 3 Michael Kay 2005-10-28 22:46:02 UTC
The spec says "... the output definition uses the value of that attribute from
the xsl:output declaration with the highest import precedence." Therefore if
doctype="" has higher import precedence than doctype="abc", the effective value
of doctype is "". There's nothing in the spec that says "" is handled
differently from any other value of the attribute: therefore it isn't handled
differently; it's an ordinary value like any other.

cdata-section-elements is different because it is cumulative: "For the
cdata-section-elements attribute, the output definition uses the union of the
values from all the constituent xsl:output declarations." (The next draft
actually has slightly revised wording to clarify that it's the union of the
expanded QNames).

Sorry if I'm being dense, but I can only see one way of reading the spec.

Michael Kay (personal response)
Comment 4 Mike Brown 2005-10-28 23:27:04 UTC
It's good to hear there will be clearer language re: cdata-section-elements.

I am not satisfied overall, but you seem to feel there is nothing to clarify and
that I am calling you dense (or perhaps you are calling me dense), so never
mind; I withdraw the request.
Comment 5 Jim Melton 2007-02-25 23:57:00 UTC
Closing bug because commenter has not objected to the resolution posted and more than two weeks have passed.