Correctly parse comments in doctype declarations #5581
Conversation
| @@ -740,7 +740,7 @@ public String getPrefix() { | |||
| } | |||
|
|
|||
| Markers markers; | |||
| List<Element> elements; | |||
| List<Content> elements; | |||
There was a problem hiding this comment.
I have a slight worry here about deserialization, but I'm not on my laptop to check.. Pointing it out here for a more thorough review.
There was a problem hiding this comment.
- Indeed, types
ElementandContentseem unrelated (other than descending fromXml). - But I agree, the external subsets shouldn't be modelled as a collection of elements. These are not elements from logical perspective.
- Having said that, I think we should go for it. As far as I understand,tThe failure scenario is that for some XML files which use these declarations, their LSTs will no longer match until re-built.
All in all - let's try.
|
Thanks a lot for the help here @jhl221123 ! I've tagged Greg for an additional review of the concern I posted above. |
|
Thank you so much for the contribution, @jhl221123. |
|
Something seems wrong here. Note that Xml.Element isn't a normal XML element. For that we have Xml.Tag. Perhaps it is meant to correspond to https://www.w3.org/TR/xml/#NT-elementdecl? AFAICT, we now no longer create any Xml.Element instances anywhere. That would mean that any recipes which operate on these or on owned objects would be broken now. Can we check this again? |
This reverts commit ebf4d2b.
Co-authored-by: Tim te Beek <tim@moderne.io>
What's changed?
This change updates the logic in
visitDoctypedeclto correctly createXml.Commentobjects for comments found within a doctype's internal subset. All other markup, such as entity declarations, is parsed asXml.CharDatato preserve its raw text.What's your motivation?
Xml.Ident#4930Checklist