remove XML algorithm and other constants from implementation and API
Basics
Logistics
Basics
Logistics
Description
Some stages, most notably XMLSignatureSigningStage, contain their own set of constants for the various URIs used in XML DSIG. Worse, these are public fields and therefore part of the API.
There's no good reason for this these days. In Java 11, all of these constants are available as part of the Java API. We should remove our duplicates, and use the Java API's version in our implementation.
Removing the fields will change the API, so should be prioritised for 0.10 so that it can be done pre-1.0.
I take that back. XMLDSIGSupport is probably a good place to put static fields representing element QName s, as those don't appear to be present in the Java API.
Ian YoungSeptember 27, 2019 at 3:34 PM
It looks like the only relevant classes are XMLSignatureSigningStage and XMLDSIGSupport. The latter only defines a single static constant field, so can be removed entirely. Some other classes may need to be modified once we remove these fields, of course.
Some stages, most notably
XMLSignatureSigningStage, contain their own set of constants for the various URIs used in XML DSIG. Worse, these arepublicfields and therefore part of the API.There's no good reason for this these days. In Java 11, all of these constants are available as part of the Java API. We should remove our duplicates, and use the Java API's version in our implementation.
Removing the fields will change the API, so should be prioritised for 0.10 so that it can be done pre-1.0.