xmllint --xpath '//element/@attribute'
There's a good chance it's already installed on your mac. xmllint --xpath '//*[local-name()="element"]/@attribute'
Note: for consistency, namespaces are not needed for attribute names.http://stackoverflow.com/questions/4402310/how-to-ignore-nam...
I agree that jq is really nice though. In particular, I still find JSON nicer than XML in the small-scale (e.g. scripts for transforming ATOM feeds) because:
- No DTDs means no unexpected network access or I/O failures during parsing
- No namespaces means names are WYSIWYG (no implicit prefixes which may/may not be needed, depending on the document)
- All text is in strings, rather than 'in between' elements
- No redundant element/attribute distinction
Even with tooling, these annoyances with XML leak through. As an example, xmlstarlet can find the authors in an ATOM file using an XPath query like '//author'; except if the document contains a default namespace, in which case it'll return no results since that XPath isn't namespaced.
This sort of silently-failing, document-dependent behaviour is really frustrating; requiring two branches (one for documents with a default-namespace, one for documents without) and text-based bash hackery to look for and dig out any default namespace prior to calling xmlstarlet :(
• Text nodes (especially whitespace text nodes)
• Comments
• Attributes vs. child nodes
• Ordering of child nodes
From the XSLT spec [0]:
"Converts an XML tree, whose format corresponds to the XML representation of JSON defined in this specification, into a string conforming to the JSON grammar"
It can't take an arbitrary XML document and turn it into JSON, it can only take XML documents that conform to a specific format.
You can safely round-trip from JSON to XML and back to JSON. That's trivial because JSONs feature set is a subset of XMLs.
What you can't safely do is round-trip from arbitrary XML to JSON and back to XML. That's because, as the parent said, there are features in XML that don't exist in JSON. That means you are forced to find a way to encode it using the features you do have, but then you can't tell your encoding apart from valid values.
{
"type": "element",
"name": "blink",
"attributes": {
"foo": "bar"
},
"children": [
{
"type": "text",
"content": "example text"
}
]
}