Project

Profile

Help

Bug #2377

closed

Private classes/methods in LinkedTree

Added by Michael Kay almost 9 years ago. Updated over 8 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Sprint/Milestone:
Start date:
2015-05-13
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
9.6
Fix Committed on Branch:
9.6
Fixed in Maintenance Release:
Platforms:

Description

A user who wants to construct instances of the LinkedTree programmatically points out that various classes/constructors/methods are unnecessarily private.

Actions #1

Updated by Michael Kay almost 9 years ago

I have changed CommentImpl, AttributeImpl, and ProcInstImpl to be public (and not final)

In DocumentImpl I have changed several setters including setDocumentElement to be public

Actions #2

Updated by Michael Kay almost 9 years ago

  • Status changed from New to Resolved
Actions #3

Updated by Ignacio Hernandez-Ros almost 9 years ago

Hi,

We miss setters in DocumentImpl in order to deal with DocType it would be nice to have a new class to hold DOCTYPE information. We have seen there is already an XSLT function to create DOCTYPE information in output tree I wonder if the functionality should be in the DocumentImpl or not.

Actions #4

Updated by Michael Kay almost 9 years ago

There's no support for DOCTYPE in XDM, and if we were adding it to DocumentImpl, then I think users would expect XPath extensions functions to get (and perhaps create the information). You say "We have seen there is already an XSLT function to create DOCTYPE information in output tree" -- I'm not sure what you are referring to. Both the xsl:output doctype-system/doctype-public properties, and the saxon:doctype extension instruction, only affect serialized output, they do not allow anything to be written to the result tree itself.

Note also that DocumentImpl provides extensibility via the setUserData() method.

Actions #5

Updated by O'Neil Delpratt almost 9 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in version set to 9.6.0.6

Bug fix applied in the Saxon 9.6.0.6 maintenance release.

Actions #6

Updated by Ignacio Hernandez-Ros over 8 years ago

O'Neil Delpratt wrote:

Bug fix applied in the Saxon 9.6.0.6 maintenance release.

Thanks, we are moving slow on our implementation and this is the reason I'm reporting this now.

If possible, we would like to create an extension class of net.sf.saxon.tree.linked.DocumentImpl (which is now final) and a method "makeDocumentNode" in the net.sf.saxon.tree.linked.NodeFactory interface to create such nodes during the XML sax parsing.

Cheers,

Ignacio

Actions #7

Updated by O'Neil Delpratt over 8 years ago

  • Sprint/Milestone set to 9.6.0.6
  • Applies to branch 9.6 added
  • Fix Committed on Branch 9.6 added
  • Fixed in Maintenance Release 9.6.0.6 added

Please register to edit this issue

Also available in: Atom PDF