Project

Profile

Help

Bug #3995

Undocumented and untested extensions to xsl:source-document

Added by Michael Kay almost 2 years ago. Updated 3 months ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
Saxon extensions
Sprint/Milestone:
-
Start date:
2018-11-04
Due date:
% Done:

0%

Estimated time:
Legacy ID:
Applies to branch:
10, 9.9
Fix Committed on Branch:
10
Fixed in Maintenance Release:

Description

The 9.9 implementation of xsl;source document includes code to implement a number of extension attributes which appear (as far as I can tell) to be undocumented and untested. These include:

saxon:dtd-validation=yes|no - controls whether DTD validation takes place

saxon:expand-attribute-defaults=yes|no - controls whether attribute defaults defined in the schema or DTD are expanded

saxon:line-numbering=yes|no - controls whether line numbers are maintained for the document

saxon:xinclude - controls whether XInclude processing takes place

saxon:strip-space - controls the whitespace stripping that is applied

These extensions should either be properly documented and tested, or removed.

History

#1 Updated by Michael Kay almost 2 years ago

  • Subject changed from Undocumented and untested extensions to xsl;source-document to Undocumented and untested extensions to xsl:source-document

#2 Updated by Michael Kay over 1 year ago

saxon:line-numbering now working and tested in xslt30extra/source-document

#3 Updated by Michael Kay over 1 year ago

saxon:strip-space now working and tested. Allowed values #all, #none, #ignorable, #default.

#4 Updated by Debbie Lockett over 1 year ago

9.9.1 release included the code fixes to allow saxon:line-numbering and saxon:strip-space attributes. The documentation has (belatedly) now been updated, see xsl-elements/source-document and extensions/attributes.

Committed on 9.9 and 10.0 dev branches. 9.9 documentation updated online (XML and HTML versions).

#5 Updated by Michael Kay 12 months ago

  • Category set to Saxon extensions
  • Status changed from New to In Progress
  • Priority changed from Low to Normal

Contrary to the documentation, these extensions are currently working in Saxon-HE. In accordance with the general policy that Saxon extensions require PE or EE, this will be changed.

#6 Updated by Michael Kay 5 months ago

  • Status changed from In Progress to Resolved
  • Applies to branch 10 added
  • Fix Committed on Branch 10 added

On the 10.0 branch I have made the change to check for a PE license when extension attributes are used.

Although this is consistent with the documentation, I will avoid adding the extra checks on the 9.9 branch in the interests of application stability.

#7 Updated by Michael Kay 5 months ago

  • Status changed from Resolved to In Progress

I don't think it is conformant to raise an error if these attributes are used on Saxon-HE

The spec (ยง3.2) says: "An implementation that does not recognize the name of an extension attribute, or that does not recognize its value, must perform the transformation as if the extension attribute were not present. As always, it is permissible to produce warning messages."

So I think we should produce a warning and ignore the attribute.

#8 Updated by Michael Kay 3 months ago

Revisiting this, and extending the scope to include options for saxon:doc(), saxon:parse(), and saxon:parse-html().

Currently xsl:source-document supports:

  • validation
  • type
  • use-accumulators
  • saxon:dtd-validation - boolean
  • saxon:expand-attribute-defaults - boolean
  • saxon:line-numbering - boolean
  • saxon:xinclude - boolean
  • saxon:strip-space - #all, #none, #ignorable, #default

saxon:doc supports:

  • validation
  • type
  • dtd-validation
  • strip-space - all, none, package-defined
  • stable - boolean, not documented, accepted but not implemented
  • accumulators - xs:QName*, implemented but not documented
  • use-xsi-schema-location - boolean, implemented but not documented

saxon:parse() and saxon:parse-html() do not have an options parameter, but I would like to give them one, especially to allow a base URI to be specified.

Other candidates for controlling parsing and document building (available in the Java ParseOptions interface) include:

  • validationParams (for validating against a parameterized schema)
  • topLevelElement
  • topLevelType
  • parser class
  • tree model
  • error handling options

Please register to edit this issue

Also available in: Atom PDF