{"action":"created","issue":{"url":"https://api.github.com/repos/JuliaLang/LightXML.jl/issues/36","labels_url":"https://api.github.com/repos/JuliaLang/LightXML.jl/issues/36/labels{/name}","comments_url":"https://api.github.com/repos/JuliaLang/LightXML.jl/issues/36/comments","events_url":"https://api.github.com/repos/JuliaLang/LightXML.jl/issues/36/events","html_url":"https://github.com/JuliaLang/LightXML.jl/issues/36","id":123253751,"number":36,"title":"Feature Request: Parsing HTML Files or Strings","user":{"login":"bkomboz","id":13077790,"avatar_url":"https://avatars.githubusercontent.com/u/13077790?v=3","gravatar_id":"","url":"https://api.github.com/users/bkomboz","html_url":"https://github.com/bkomboz","followers_url":"https://api.github.com/users/bkomboz/followers","following_url":"https://api.github.com/users/bkomboz/following{/other_user}","gists_url":"https://api.github.com/users/bkomboz/gists{/gist_id}","starred_url":"https://api.github.com/users/bkomboz/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bkomboz/subscriptions","organizations_url":"https://api.github.com/users/bkomboz/orgs","repos_url":"https://api.github.com/users/bkomboz/repos","events_url":"https://api.github.com/users/bkomboz/events{/privacy}","received_events_url":"https://api.github.com/users/bkomboz/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":8,"created_at":"2015-12-21T10:46:18Z","updated_at":"2015-12-22T07:44:04Z","closed_at":null,"body":"This is a feature request/question: What do you think about adding support for parsing HTML files and strings to `LightXML.jl` via the `HTMLparser` module of `libxml2`? \r\n\r\nTwo possible strategies to implement this functionality come to my mind:\r\n1. Adding an argument to `parse_file` indicating whether it is a XML or a HTML file which has to be parsed and then internally chosing the corresponding `libxml2` function.\r\n2. Renaming `parse_file` (and similar functions) to `parse_xml[file]` [thus breaking the existing api] and adding `parse_html[file]` (and similar functions).\r\n\r\nIn addition one would have to think how to represent HTML documents (e.g., a separate `HTMLDocument` type which has a common supertype with the existing `XMLDocument` type?)\r\n\r\nWhat do you think? I would love to have this functionality and would vote for implementation strategy 2. with some transition phase for depracating `parse_file` and similar functions. Overall I think it is cleaner. I could try to set up a prototype if there is support for this feature."},"comment":{"url":"https://api.github.com/repos/JuliaLang/LightXML.jl/issues/comments/166543158","html_url":"https://github.com/JuliaLang/LightXML.jl/issues/36#issuecomment-166543158","issue_url":"https://api.github.com/repos/JuliaLang/LightXML.jl/issues/36","id":166543158,"user":{"login":"tkelman","id":5934628,"avatar_url":"https://avatars.githubusercontent.com/u/5934628?v=3","gravatar_id":"","url":"https://api.github.com/users/tkelman","html_url":"https://github.com/tkelman","followers_url":"https://api.github.com/users/tkelman/followers","following_url":"https://api.github.com/users/tkelman/following{/other_user}","gists_url":"https://api.github.com/users/tkelman/gists{/gist_id}","starred_url":"https://api.github.com/users/tkelman/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tkelman/subscriptions","organizations_url":"https://api.github.com/users/tkelman/orgs","repos_url":"https://api.github.com/users/tkelman/repos","events_url":"https://api.github.com/users/tkelman/events{/privacy}","received_events_url":"https://api.github.com/users/tkelman/received_events","type":"User","site_admin":false},"created_at":"2015-12-22T07:44:04Z","updated_at":"2015-12-22T07:44:04Z","body":"HTML parsing **is** a special case. It's new untested functionality that has not been written yet, contributed by someone who's totally new to the community. I don't doubt that you're technically capable, but right now there's a non-negligible chance that you might write this html code then vanish without maintaining it going forward (as the original author of this package has done). So I think you should aim to add new functionality in a minimally disruptive way, get it into the package and tested first. Then long term we could maybe think about refactoring to make HTML functionality less of a second-class citizen. But it's going to have to start that way, since it doesn't exist yet. You'd have more freedom to design things however you like if you use a separate package, so it depends how much code will really be shared."}}