-
Notifications
You must be signed in to change notification settings - Fork 6.2k
8351969: Add Public Identifiers to the JDK built-in Catalog #24039
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
👋 Welcome back joehw! A progress list of the required criteria for merging this PR into |
|
@JoeWang-Java This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be: You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 59 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
|
@JoeWang-Java The following label will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command. |
Webrevs
|
myankelev
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, just a few very minor questions. Thank you
| public void setUpClass() throws Exception { | ||
| // initialize JDKCatalog | ||
| JdkCatalog.init("continue"); | ||
| jdkCatalog = JdkCatalog.catalog; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems to be a set up just for 1 test. Do you think it might be better to have this logic in the beginning of the testDTDsInJDKCatalog?
| static final String TARGET_NAMESPACE = "{{targetNamespace}}"; | ||
| static final String ROOT_ELEMENT = "{{rootElement}}"; | ||
|
|
||
| Catalog jdkCatalog; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nitpick: if this will stay as a global var I'd personally make it private and move to the top of the file. What do you think?
| * @test | ||
| * @bug 8344800 8345353 | ||
| * @bug 8344800 8345353 8351969 | ||
| * @modules java.xml/jdk.xml.internal |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know that this is not a part of your change, but this (line 56) doesn't seem to be used at all. Could you please remove it if there will be another revision? If not it's ok as is 😄
static String CLS_DIR = System.getProperty("test.classes");
| */ | ||
| @Test(dataProvider = "DTDsInJDKCatalog") | ||
| public void testDTDsInJDKCatalog(String publicId, String systemId) | ||
| throws Exception { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Don't think throw exception is doing anything here.
| * Data provided: public and system Ids, see test testDTDsInJDKCatalog | ||
| */ | ||
| @DataProvider(name = "DTDsInJDKCatalog") | ||
| public Object[][] getDTDsInJDKCatalog() throws Exception { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Don't think throw exception is doing anything here.
|
Thanks for review. Updated the test. |
Thank you! |
LanceAndersen
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
changes look OK Joe
RogerRiggs
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The XMLSchema.dtd changes the referenced version from the 2009 version to the 2001 version. Is that intentional.
| <!-- $Id: XMLSchema.dtd,v 1.31 2001/10/24 15:50:16 ht Exp $ --> | ||
| <!-- Note this DTD is NOT normative, or even definitive. --> <!--d--> | ||
| <!-- prose copy in the structures REC is the definitive version --> <!--d--> | ||
| <!-- (which shouldn't differ from this one except for this --> <!--d--> | ||
| <!-- comment and entity expansions, but just in case) --> <!--d--> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The other XML comments use the multi-line format with a single begin
What is the meaning of ""?
Is "REC" a typo?
The comment seems unnecessarily apologetic. It should be sufficient to say:
Note: this DTD is NOT normative, any differences from RFC XXX are insidential". (or similar).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense. The question would be, would we want to modify the standard file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Likely, a number of my comments were due to comparing with the wrong XMLSchema.data version.
| <!ENTITY % xs-datatypes PUBLIC 'datatypes' 'datatypes.dtd' > | ||
|
|
||
| <!ENTITY % p 'xs:'> <!-- can be overridden in the internal subset of a | ||
| <!ENTITY % p 'xs:'> <!-- can be overriden in the internal subset of a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The original version is correct "overridden".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typos in the original should be retained to avoid gratuitous difference.
| */ | ||
| package common.jdkcatalog; | ||
|
|
||
| import static jaxp.library.JAXPTestUtilities.SRC_DIR; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Static imports across classes (even with a package) make it harder to read the test and know where it is imported from. The reference in the source here should include the class its imported from.
| String matchingPubId = JDKCATALOG.matchPublic(publicId); | ||
| String matchingSysId = JDKCATALOG.matchSystem(systemId); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't there a public API to get these values. It seems a bit of a hack to have to break module encapsulation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated. Thanks!
Yes. Note the Public Identifier: "-//W3C//DTD XSD 1.1//EN" vs "-//W3C//DTD XMLSCHEMA 200102//EN" at line 2. The 2009 version was for Schema 1.1 while the 2001 version for Schema 1.0. As shown in the JDKCatalog.xml, only Schema 1.0 is included in the catalog. It's a bit unfortunate the files were named the same. The 1.1 version file was indeed better formatted/worded. But since this is standard file, it was a simple copy without modification. |
RogerRiggs
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The .dtds look fine.
Thanks for the update to the test.
| <!ENTITY % xs-datatypes PUBLIC 'datatypes' 'datatypes.dtd' > | ||
|
|
||
| <!ENTITY % p 'xs:'> <!-- can be overridden in the internal subset of a | ||
| <!ENTITY % p 'xs:'> <!-- can be overriden in the internal subset of a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typos in the original should be retained to avoid gratuitous difference.
|
Thanks all for the reviews! |
|
/integrate |
|
Going to push as commit 8e999b8.
Your commit was automatically rebased without conflicts. |
|
@JoeWang-Java Pushed as commit 8e999b8. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Add public identifiers to the JDK built-in Catalog; Replace the incorrect Schema 1.1 DTD files (note the Public Identifier at line 2) with the correct Schema 1.0 DTDs. The JDK built-in Catalog contains Schema 1.0 files only.
DTD files: the Schema 1.1 files, XMLSchema.dtd and datatypes.dtd, were removed and replaced with those of Schema 1.0. These files were downloaded from w3.org without modification. The file names were unfortunately the same, which (with the Diffs) made it look like they were modified though they were not.
Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/24039/head:pull/24039$ git checkout pull/24039Update a local copy of the PR:
$ git checkout pull/24039$ git pull https://git.openjdk.org/jdk.git pull/24039/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 24039View PR using the GUI difftool:
$ git pr show -t 24039Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/24039.diff
Using Webrev
Link to Webrev Comment