Coder Social home page Coder Social logo

multi_xml's Introduction

MultiXML

A generic swappable back-end for XML parsing

Installation

gem install multi_xml

Documentation

http://rdoc.info/gems/multi_xml

Usage Examples

require 'multi_xml'

MultiXml.parser = :ox
MultiXml.parser = MultiXml::Parsers::Ox # Same as above
MultiXml.parse('<tag>This is the contents</tag>') # Parsed using Ox

MultiXml.parser = :libxml
MultiXml.parser = MultiXml::Parsers::Libxml # Same as above
MultiXml.parse('<tag>This is the contents</tag>') # Parsed using LibXML

MultiXml.parser = :nokogiri
MultiXml.parser = MultiXml::Parsers::Nokogiri # Same as above
MultiXml.parse('<tag>This is the contents</tag>') # Parsed using Nokogiri

MultiXml.parser = :rexml
MultiXml.parser = MultiXml::Parsers::Rexml # Same as above
MultiXml.parse('<tag>This is the contents</tag>') # Parsed using REXML

MultiXml.parser = :oga
MultiXml.parser = MultiXml::Parsers::Oga # Same as above
MultiXml.parse('<tag>This is the contents</tag>') # Parsed using Oga

The parser setter takes either a symbol or a class (to allow for custom XML parsers) that responds to .parse at the class level.

MultiXML tries to have intelligent defaulting. That is, if you have any of the supported parsers already loaded, it will use them before attempting to load a new one. When loading, libraries are ordered by speed: first Ox, then LibXML, then Nokogiri, and finally REXML.

Supported Ruby Versions

This library aims to support and is tested against the following Ruby implementations:

  • 3.0
  • 3.1
  • 3.2

If something doesn't work on one of these versions, it's a bug.

This library may inadvertently work (or seem to work) on other Ruby implementations, however support will only be provided for the versions listed above.

If you would like this library to support another Ruby version, you may volunteer to be a maintainer. Being a maintainer entails making sure all tests run and pass on that implementation. When something breaks on your implementation, you will be responsible for providing patches in a timely fashion. If critical issues for a particular implementation exist at the time of a major release, support for that Ruby version may be dropped.

Inspiration

MultiXML was inspired by MultiJSON.

Copyright

Copyright (c) 2010-2023 Erik Berlin. See LICENSE for details.

multi_xml's People

Contributors

avsej avatar brixen avatar fisherwebdev avatar guycall avatar hakanensari avatar joshk avatar ka8725 avatar koic avatar koraktor avatar olleolleolle avatar pearkes avatar phiggins avatar sferik avatar stve avatar tcocca avatar trevorrowe avatar valtri avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

multi_xml's Issues

uninitialized class variable @@parser in MultiXml (NameError)

With the new 0.5.0 version of the gem when MultiXml tries to initialize we get the following error:

multi_xml.rb:60:in `parser': uninitialized class variable @@parser in MultiXml (NameError)

Unless we set MultiXml.parser = :something first. I want to make sure this is intended behavior now that you have to explicitly set the parser that you wish to use?

This was introduced in the following commit:
b562bed

Failing tests for multi_xml 0.4.1 with ruby 1.9.3

With ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-linux] I'm getting three similar test failures:

  1) MultiXml LibXML parser it should behave like a parser.parse a valid XML document with an attribute type="decimal" should return the correct number
     Failure/Error: MultiXml.parse(@xml)['tag'].should == 3.14159265358979323846264338327950288419716939937510
       expected: 3.141592653589793
            got: #<BigDecimal:157b060,'0.3141592653 5897932384 6264338327 9502884197 1693993751E1',63(63)> (using ==)
     Shared Example Group: "a parser" called from ./spec/multi_xml_spec.rb:35


  2) MultiXml REXML parser it should behave like a parser.parse a valid XML document with an attribute type="decimal" should return the correct number
     Failure/Error: MultiXml.parse(@xml)['tag'].should == 3.14159265358979323846264338327950288419716939937510
       expected: 3.141592653589793
            got: #<BigDecimal:15d52b8,'0.3141592653 5897932384 6264338327 9502884197 1693993751E1',63(63)> (using ==)
     Shared Example Group: "a parser" called from ./spec/multi_xml_spec.rb:35

  3) MultiXml Nokogiri parser it should behave like a parser.parse a valid XML document with an attribute type="decimal" should return the correct number
     Failure/Error: MultiXml.parse(@xml)['tag'].should == 3.14159265358979323846264338327950288419716939937510
       expected: 3.141592653589793
            got: #<BigDecimal:6691f8,'0.3141592653 5897932384 6264338327 9502884197 1693993751E1',63(63)> (using ==)
     Shared Example Group: "a parser" called from ./spec/multi_xml_spec.rb:35

Inconsistent handling of "empty" elements.

Given the following Gemfile

source 'https://rubygems.org'

gem 'multi_xml'
gem 'nokogiri'
gem 'ox'
gem 'libxml-ruby'

Given the following Gemfile.lock

GEM
  remote: https://rubygems.org/
  specs:
    libxml-ruby (2.8.0)
    mini_portile (0.6.2)
    multi_xml (0.5.5)
    nokogiri (1.6.6.2)
      mini_portile (~> 0.6.0)
    ox (2.1.8)

PLATFORMS
  ruby

DEPENDENCIES
  libxml-ruby
  multi_xml
  nokogiri
  ox

And the following script:

require 'bundler/setup'
require 'multi_xml'
require 'libxml'
require 'ox'
require 'nokogiri'

xml = '<xml> </xml>'

[:nokogiri, :rexml, :ox, :libxml].each do |parser|
  MultiXml.parser = parser
  puts "#{parser}: #{MultiXml.parse(xml).inspect}"
end

I get the following output:

nokogiri: {"xml"=>nil}
rexml: {"xml"=>" "}
ox: {"xml"=>" "}
libxml: {"xml"=>nil}

Looking for versioning guidance

I would like to use multi_xml gem in a project I am currently developing. I did not notice any guidance in the README around versioning of the published gem. Does this project follow semver or some other established versioning pattern?

What I'm trying to nail down is a simple gem dependency string that will allow users to pick up updates without breaking changes. I was considering using '~> 0.5', any thoughts?

Set parser at parse time

Currently it seems that it is only possible to specify a parser for MultiXml to use at the class level like so: MultiXml.parser = :ox. However, this makes it quite awkward to use different parsers in the same application. It would be preferable to allow the parser to be set for individual parse operations like so: MultiXml.parse(xml, parser: :ox). If there's support for this idea, I would be happy to put together a PR.

Add bigdecimal to gemspec

Hi,
due to gemification of the Ruby standard library [1], I think you should include bigdecimal gem in gemspec of multi_xml - if new version of bigdecimal is released, you will need to add it there anyway, so that bundler doesn't pick up the bigdecimal that is bundled in the standard Ruby installation.

Thank you!

[1] https://bugs.ruby-lang.org/issues/5481

undefined method `sax_parse' for Ox:Module

Im using faraday and faraday_middleware libraries for the xml response parsing from external API.

Im running this in a multi threaded process
Im getting this error when I call object.get.body

object = Faraday.new 'url' do |conn|
conn.headers['referer'] = 'referer url'
conn.response :xml
conn.adapter Faraday.default_adapter
end

object.params = {:id => 123}

when I call object.get.body , throws this exception

error backtrace

/usr/local/rvm/gems/ruby-2.2.2/gems/multi_xml-0.5.5/lib/multi_xml.rb:138:in parse' /usr/local/rvm/gems/ruby-2.2.2/gems/faraday_middleware-0.9.1/lib/faraday_middleware/response/parse_xml.rb:9:inblock in class:ParseXml'
/usr/local/rvm/gems/ruby-2.2.2/gems/faraday_middleware-0.9.1/lib/faraday_middleware/response_middleware.rb:48:in call' /usr/local/rvm/gems/ruby-2.2.2/gems/faraday_middleware-0.9.1/lib/faraday_middleware/response_middleware.rb:48:inparse'
/usr/local/rvm/gems/ruby-2.2.2/gems/faraday_middleware-0.9.1/lib/faraday_middleware/response_middleware.rb:39:in process_response' /usr/local/rvm/gems/ruby-2.2.2/gems/faraday_middleware-0.9.1/lib/faraday_middleware/response_middleware.rb:32:inblock in call'
/usr/local/rvm/gems/ruby-2.2.2/gems/faraday-0.9.1/lib/faraday/response.rb:57:in on_complete' /usr/local/rvm/gems/ruby-2.2.2/gems/faraday_middleware-0.9.1/lib/faraday_middleware/response_middleware.rb:30:incall'
/usr/local/rvm/gems/ruby-2.2.2/gems/faraday-0.9.1/lib/faraday/rack_builder.rb:139:in build_response' /usr/local/rvm/gems/ruby-2.2.2/gems/faraday-0.9.1/lib/faraday/connection.rb:377:inrun_request'
/usr/local/rvm/gems/ruby-2.2.2/gems/faraday-0.9.1/lib/faraday/connection.rb:140:in `get'

Lossy Conversion from XML to Hash

So the only return result is a Hash? That's very limited. A Hash can't encode all the aspects of an XML document.

I started a project kind of like this some time ago called Cherry. But with it I just created a common API for working on the each underlying back-end via adapters. Considering what you are doing here, on retrospect I probably should have kept my own internal representation of the XML, and used the the high level API for manipulating that model. Then convert it back into any other representations (LibXML, Nokogiri, REXML). That seems like a good idea for Multi-XML too.

Switching parser backend is not threadsafe

I've written a gem that is using MultiXml to parse a response from a 3rd party API. Due to some peculiarities of the response XML, this gem is forced to use the Ox backend. The client using this gem also has other dependencies which use MultiXml, though I'm not sure which back-end they prefer. Given that different backends result in different parsing behavior (see #30), I foresee disaster if I force all dependencies to use Ox (or if one of the dependencies forces my gem to use a backend other than Ox).

The naive solution would be to wrap calls to MultiXml.parse in my gem like so

def parse_xml(xml)
  orig_parser = MultiXml.parser
  MultiXml.parser = :ox
  parsed = MultiXml.parse(xml)
  MultiXml.parser = orig_parser
  parsed
end

Unfortunately, this won't work for me, because the client application is running in a multithreaded environment (Rails with Puma) and this approach is not thread-safe.

What I need is a thread safe way to tell my gem to use Ox when parsing without affecting other gems' usage of MultiXml.

One solution would be to add a :parser option to MultiXml.parse, which would override the globally configured parser for that particular case. Usage could look like

MutliXml.parse(xml, parser: :ox)

That is just a suggested solution, I know there are other ways to solve this problem too.

Default parser is broken in new Rubinius

The new Rubinius doesn't bundle the standard library, so unless user includes rubysl-rexml in her Gemfile, MultiXml.default_parser fails to load a parser and unexpectedly returns REQUIREMENT_MAP.

Simplest solution is to guard at the end the method by raising a descriptive message.

Make parsing errors inspectable

When parsing fails I get something like:

/Users/mgrosser/.rvm/gems/ruby-1.9.3-p194/gems/multi_xml-0.5.1/lib/multi_xml/parsers/nokogiri.rb:16:in `parse': Opening and ending tag mismatch: meta line 4 and head (Faraday::Error::ParsingError)
    from /Users/mgrosser/.rvm/gems/ruby-1.9.3-p194/gems/multi_xml-0.5.1/lib/multi_xml.rb:119:in `parse'
    from /Users/mgrosser/.rvm/gems/ruby-1.9.3-p194/gems/faraday_middleware-0.8.7/lib/faraday_middleware/response/parse_xml.rb:9:in `block in <class:ParseXml>'
    from /Users/mgrosser/.rvm/gems/ruby-1.9.3-p194/gems/faraday_middleware-0.8.7/lib/faraday_middleware/response_middleware.rb:48:in `call'

which is pretty hard to debug, so how about raising a MultiXml::ParsingError that has .original_exception and .xml so the cause is easy to inspect

some tests failing with newer ox gem (>= 2.4.13)

Hi!

I tried to run the tests for various version of the ox gem. Whereas they pass from 2.4.2 (the one used in the latest Travis test it seems) and with all versions up to 2.4.12, they start failing with 2.4.13.

With the latest one (2.8.2 as I write), I got one test failure:

Failures:

  1) MultiXml Ox parser behaves like a parser .parse a valid XML document with an attribute type="yaml" returns the correctly parsed YAML when the type is allowed
     Failure/Error: expect(MultiXml.parse(@xml, :disallowed_types => [])['tag']).to eq(:message => 'Have a nice day', 1 => 'returns an integer', 'array' => [{'has-dashes' => true, 'has_underscores' => true}])
     
       expected: {:message=>"Have a nice day", 1=>"returns an integer", "array"=>[{"has-dashes"=>true, "has_underscores"=>true}]}
            got: "--- 1: returns an integer :message: Have a nice day array: - has-dashes: true has_underscores: true "
     
       (compared using ==)
     
       Diff:
       @@ -1,4 +1,2 @@
       -"array" => [{"has-dashes"=>true, "has_underscores"=>true}],
       -1 => "returns an integer",
       -:message => "Have a nice day",
       +"--- 1: returns an integer :message: Have a nice day array: - has-dashes: true has_underscores: true "
       
     Shared Example Group: "a parser" called from ./spec/multi_xml_spec.rb:45
     # ./spec/parser_shared_example.rb:335:in `block (5 levels) in <top (required)>'

Finished in 0.15025 seconds (files took 0.40745 seconds to load)
336 examples, 1 failure

Failed examples:

rspec ./spec/multi_xml_spec.rb[1:5:1:1:5:18:2] # MultiXml Ox parser behaves like a parser .parse a valid XML document with an attribute type="yaml" returns the correctly parsed YAML when the type is allowed

Randomized with seed 31053

This affects the version of ruby-multi-xml currently in Debian (0.5.3)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882718
but also the current 0.6 which is being packaged.

It seems related to the following:

Common error handling for all parsers

All exceptions from the parsers should be caught and translated into a MultiXml exception so that the user can consistently catch exceptions, independent of the parser.

Inconsistency with rexml parser

This is somehow related to #30
However intoduces inconsistency with rexml parser this time.

xml = %q{<feed xmlns:gd='http://schemas.google.com/g/2005'> <entry gd:etag='sample'></entry></feed>}
MultiXml.parser = :rexml
MultiXml.parse xml
# => {"feed"=>{"xmlns:gd"=>"http://schemas.google.com/g/2005", "entry"=>{"gd:etag"=>"sample"}}}
MultiXml.parser = :libxml
MultiXml.parse xml
# => {"feed"=>{"entry"=>{"etag"=>"sample"}}}

Using libxml and nokogiri I have parsed_body["feed"]["entry"]["etag"], but with rexml I have parsed_body["feed"]["entry"]["gd:etag"]

libxml and oga not working in 2.6.x

With ruby 2.6.3 some parsers are not working.

irb(main):007:0> MultiXml.parser = :libxml
Traceback (most recent call last):
       11: from /home/noraj/.rbenv/versions/2.6.3/bin/irb:23:in `<main>'
       10: from /home/noraj/.rbenv/versions/2.6.3/bin/irb:23:in `load'
        9: from /home/noraj/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/irb-1.0.0/exe/irb:11:in `<top (required)>'
        8: from (irb):7
        7: from (irb):7:in `rescue in irb_binding'
        6: from /home/noraj/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/multi_xml-0.6.0/lib/multi_xml.rb:115:in `parser='
        5: from /home/noraj/.rbenv/versions/2.6.3/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
        4: from /home/noraj/.rbenv/versions/2.6.3/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
        3: from /home/noraj/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/multi_xml-0.6.0/lib/multi_xml/parsers/libxml.rb:1:in `<top (required)>'
        2: from /home/noraj/.rbenv/versions/2.6.3/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
        1: from /home/noraj/.rbenv/versions/2.6.3/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
irb(main):011:0> MultiXml.parser = :oga
Traceback (most recent call last):
       10: from /home/noraj/.rbenv/versions/2.6.3/bin/irb:23:in `<main>'
        9: from /home/noraj/.rbenv/versions/2.6.3/bin/irb:23:in `load'
        8: from /home/noraj/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/irb-1.0.0/exe/irb:11:in `<top (required)>'
        7: from (irb):11
        6: from /home/noraj/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/multi_xml-0.6.0/lib/multi_xml.rb:115:in `parser='
        5: from /home/noraj/.rbenv/versions/2.6.3/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
        4: from /home/noraj/.rbenv/versions/2.6.3/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
        3: from /home/noraj/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/multi_xml-0.6.0/lib/multi_xml/parsers/oga.rb:1:in `<top (required)>'
        2: from /home/noraj/.rbenv/versions/2.6.3/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
        1: from /home/noraj/.rbenv/versions/2.6.3/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'

Losing Attributes on the node parsing when converting to a hash

I have the following XML:

<table><name>Affordability Data</name><data><attribute><name>Zillow Home Value Index</name><values><neighborhood><value type="USD">303800</value></neighborhood><city><value type="USD">349200</value></city><nation><value type="USD">146200</value></nation></values></attribute><attribute><name>Median Single Family Home Value</name><values><neighborhood><value type="USD">382600</value></neighborhood><city><value type="USD">389100</value></city><nation><value type="USD">146400</value></nation></values></attribute><attribute><name>Median Condo Value</name><values><neighborhood><value type="USD">256500</value></neighborhood><city><value type="USD">240200</value></city><nation><value type="USD">145200</value></nation></values></attribute><attribute><name>Median 2-Bedroom Home Value</name><values><neighborhood><value type="USD">313600</value></neighborhood><city><value type="USD">304000</value></city><nation><value type="USD">109800</value></nation></values></attribute><attribute><name>Median 3-Bedroom Home Value</name><values><neighborhood><value type="USD">366600</value></neighborhood><city><value type="USD">387500</value></city><nation><value type="USD">140900</value></nation></values></attribute><attribute><name>Median 4-Bedroom Home Value</name><values><neighborhood><value type="USD">410800</value></neighborhood><city><value type="USD">461100</value></city><nation><value type="USD">231000</value></nation></values></attribute><attribute><name>Percent Homes Decreasing</name><values><neighborhood><value type="percent">0.562</value></neighborhood><city><value type="percent">0.546</value></city><nation><value type="percent">0.558</value></nation></values></attribute><attribute><name>Percent Listing Price Reduction</name><values><neighborhood><value type="percent">0.278</value></neighborhood><city><value type="percent">0.298</value></city><nation><value type="percent">0.289</value></nation></values></attribute><attribute><name>Median List Price Per Sq Ft</name><values><neighborhood><value type="USD">274</value></neighborhood><city><value type="USD">253</value></city><nation><value type="USD">92</value></nation></values></attribute><attribute><name>Median List Price</name><values><neighborhood><value type="USD">325000</value></neighborhood><city><value type="USD">350000</value></city><nation><value type="USD">185000</value></nation></values></attribute><attribute><name>Median Sale Price</name><values><neighborhood><value type="USD">355500</value></neighborhood><city><value type="USD">375700</value></city><nation><value type="USD">176500</value></nation></values></attribute><attribute><name>Homes For Sale</name><values></values></attribute><attribute><name>Homes Recently Sold</name><values><neighborhood><value>15</value></neighborhood><city><value>705</value></city><nation><value>267974</value></nation></values></attribute><attribute><name>Property Tax</name><values><neighborhood><value type="USD">2767</value></neighborhood><city><value type="USD">3565</value></city><nation><value type="USD">2105</value></nation></values></attribute><attribute><name>Turnover (Sold Within Last Yr.)</name><values><neighborhood><value type="percent">0.054</value></neighborhood><city><value type="percent">0.042</value></city><nation><value type="percent">0.033</value></nation></values></attribute><attribute><name>Median Value Per Sq Ft</name><values><neighborhood><value type="USD">296</value></neighborhood><city><value type="USD">270</value></city><nation><value type="USD">106</value></nation></values></attribute><attribute><name>1-Yr. Change</name><values><neighborhood><value type="percent">-0.017</value></neighborhood><city><value type="percent">-0.022</value></city><nation><value type="percent">-0.031</value></nation></values></attribute><attribute><name>Homes For Sale By Owner</name><values><neighborhood><value>1</value></neighborhood><city><value>42</value></city><nation><value>49532</value></nation></values></attribute><attribute><name>New Construction</name><values><neighborhood><value>0</value></neighborhood><city><value>28</value></city><nation><value>44099</value></nation></values></attribute><attribute><name>Foreclosures</name><values><neighborhood><value>7</value></neighborhood><city><value>485</value></city><nation><value>512325</value></nation></values></attribute></data></table>

This parses fine in Nokogiri, but when it is run through the MultiXML.parse method I lose the "type='percent'" or "type='USD'" attributes off od the nodes in the XML. Why is this happening, I would imagine that those should come through in the hash somehow.

~ Tom

Inconsistent namespaces handling

As was previously noted in #30 and #31, namespaces are being handled differently in each implementation. However, only two libraries behave consistently so there is no preferred way to handle namespaces. Also, it doesn't seem to be a bug in libxml, just a different default behaviour of each library. I have created this mini test for comparison: https://gist.github.com/jnv/11763399bcfcead72a2c

The source document contains namespaces both for elements and attributes.

Rexml drops namespaces for elements, but keeps attributes:

{"feed"=>
  {"xmlns"=>"http://kosapi.feld.cvut.cz/schema/3",
   "xmlns:atom"=>"http://www.w3.org/2005/Atom",
   "xmlns:osearch"=>"http://a9.com/-/spec/opensearch/1.1/",
   "xmlns:xlink"=>"http://www.w3.org/1999/xlink",
   "xmlns:xsi"=>"http://www.w3.org/2001/XMLSchema-instance",
   "xml:base"=>"https://kosapi.fit.cvut.cz/api/3",
   "xml:lang"=>"cs",
   "link"=>{"atom:rel"=>"next", "href"=>"courses?offset=10&limit=10"},
   "startIndex"=>"0"}}

Nokogiri and libxml behave the same, they drop namespaces both for elements and attributes:

{"feed"=>
  {"link"=>{"rel"=>"next", "href"=>"courses?offset=10&limit=10"},
   "startIndex"=>"0",
   "base"=>"https://kosapi.fit.cvut.cz/api/3",
   "lang"=>"cs"}}

Ox keeps all namespaces:

{"atom:feed"=>
  {"xmlns"=>"http://kosapi.feld.cvut.cz/schema/3",
   "xmlns:atom"=>"http://www.w3.org/2005/Atom",
   "xmlns:osearch"=>"http://a9.com/-/spec/opensearch/1.1/",
   "xmlns:xlink"=>"http://www.w3.org/1999/xlink",
   "xmlns:xsi"=>"http://www.w3.org/2001/XMLSchema-instance",
   "xml:base"=>"https://kosapi.fit.cvut.cz/api/3",
   "xml:lang"=>"cs",
   "atom:link"=>
    {"atom:rel"=>"next", "href"=>"courses?offset=10&limit=10"},
   "osearch:startIndex"=>"0"}}

Dropping all namespaces would be the easiest solution, however this may lead to name clashes, especially considering that attrattributes and elements are merged into the same hash.

Ox's behaviour seems most correct to me, though it copies names verbatim which may cause problems, for example <atom:rel atom:href="..."> and <atom:rel href="..."> results two different hash keys; same goes for Rexml.

Any ideas how this should be handled?

cc @flexik

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.