NCBI still emits XML from their most prominent databases (e.g., PubMed). I'm looking forward to adopting this library into some of my production code that interfaces with PubMed!
Xee: A Modern XPath and XSLT Engine in Rust
221–230 of 245 posts
Re: Xee: A Modern XPath and XSLT Engine in Rust
#222Earlier quoted context omitted.
`{ type: "p", children: [{type: "text", text: "How would you represent "}, {type: "b", children: [{type: "i", children: [{type: "text", text: "mixed content"}]], {type: "text", text: " in JSON?"]}` or: `{paragraphs: [{spans: [{ text: "How you represent "}, {bold: true, italic: true, text: "mixed content"},{text: " in JSON?"}]}`
But that's terrible! How is that better? And can you guarantee correct ordering?
["p", "How would you represent ", ["b", ["i", "mixed content"]], " in JSON?"]Re: Xee: A Modern XPath and XSLT Engine in Rust
#223Earlier quoted context omitted.
How would you represent mixed content in JSON?
`{ type: "p", children: [{type: "text", text: "How would you represent "}, {type: "b", children: [{type: "i", children: [{type: "text", text: "mixed content"}]], {type: "text", text: " in JSON?"]}` or: `{paragraphs: [{spans: [{ text: "How you represent "}, {bold: true, italic: true, text: "mixed content"},{text: " in JSON?"}]}`
Oh sure, it can be represented. But now JSON is the one being noisy, ugly and verbose.
Re: Xee: A Modern XPath and XSLT Engine in Rust
#224The fact it could be compiled in WASM is a good thing, given the Chrome team was considering removing libxml and XSLT support a few years back. The reasons cited were mostly about security (and share of users). It's another proof that working on fundamental tools is a good thing.
not WASM but there is also https://www.npmjs.com/package/saxon-js
This is pretty slow compared to libxslt.
Re: Xee: A Modern XPath and XSLT Engine in Rust
#225Earlier quoted context omitted.
> It seems to me that any XML structure can be represented in JSON Well it can't: JSON has no processing instructions, no references, no comments, JSON "numbers" are problematic, and JSON arrays can't have attributes, so you're stuck with some kind of additional protocol that maps the two. For something that is basically text (like an HTML document) or a list of dictionaries (like RSS) it may not seem obvious what th…
I think I can see something of where you're coming from. But a question: You complain about dates in JSON (really a specific case of parsing text in JSON): > If they implement dates, sometimes it's unix-time, sometimes it's 1000x off from > that, sometimes it's a ISO8601-inspired string, and fuck sometimes I just get an > HTTP date. And so on. Sure, but does not XML have the exact same problem because everything is j…
> Sure, but does not XML have the exact same problem because everything is just a text?
No, you can specify what type an attribute (or element) is in the XSD (for example, xs:dateTime or xs:date). And there is only one way to specify a date in XML, and it's ISO8601. Of course JSON schema does exist, but it's mostly an afterthought.
Re: Xee: A Modern XPath and XSLT Engine in Rust
#226Earlier quoted context omitted.
This looks like it loses the distinction between attributes and nested tags? As in, I don't see a difference between `(attr "val")` which expresses an attribute key/value pair and `(thing "world")` which expresses a tag/content relationship. Even if I thought the rule might be "if the first element of the list is a list itself then it should be interpreted as a set of attribute key value pairs" then I would still be…
There's no ambiguity. The first element is a symbol that's the name of a tag. If the second element is a list of two element symbol + string lists, it's the attributes. If it's one of the other recognized types, it's part of the contents of the tag. See a grammar for the representation at https://docs.racket-lang.org/xml/index.html#%28def._%28%28li... Most Scheme tools for working with XML use a different layout wher…
I see, so my example should be:
(foo (bar "baz") "content")
(foo ((bar "baz")) "content")
I would prefer the differentiation to be more explicit than the position and/or structure of the list, so the @ symbol modifier for the attribute list in other tools makes sense.
The sibling comment with a map with a :attrs key feels even better. I don't work in languages with pattern matching or that kind of thing very often, but if I was wanting to know if a particular element had 1 or more attributes then being able to check a dictionary key just feels like a nicer kind of anchor point to match against.
Re: Xee: A Modern XPath and XSLT Engine in Rust
#227Earlier quoted context omitted.
This looks like it loses the distinction between attributes and nested tags? As in, I don't see a difference between `(attr "val")` which expresses an attribute key/value pair and `(thing "world")` which expresses a tag/content relationship. Even if I thought the rule might be "if the first element of the list is a list itself then it should be interpreted as a set of attribute key value pairs" then I would still be…
> In fact, this ambiguity between attributes and children has always been one of the head scratching things for me about XML. Well, the thing I've always disliked the most is namespaces but that is another matter. Just remember that it's a markup language, and then it's not head-scratching at all: the text is the text being marked up, and the attribute values are the attribute of the markup - things like colour and f…
When you say "those people", you mean people like me who (used to) have to navigate how to model structured data using XML. I think the attribute vs. child distinction makes sense in a very flat hierarchy where you are marking up text but quickly devolves into ambiguity for many other uses cases.
I mean, if I'm modeling a node in some structured format, making a decision about "what is the attribute of the person node" vs "what is a property of the specific Person" isn't an easy call to make in all cases. And then there are cases where an attribute itself ought to have some kind of hierarchy. Even the text example works here: I have a set of font properties and it would make sense to maybe have:
...
...
I just don't think the distinction works well for an extensible markup language where the nesting of elements is more or less the entire point.
It is much easier to write out though, which is why you see often see `` patterns all over the place.
Re: Xee: A Modern XPath and XSLT Engine in Rust
#228Earlier quoted context omitted.
I find for deeply hierarchical data that XML is much easier to read.
interrsting. I find the signal/noise ratio of XML really bad. what I really dread in XML though is that XML only has idref/id standardized, and no path references. so without tool support you can't navigate to a reference target. which turns XML into the "binary" format for GUI tools.
> so without tool support you can't navigate to a reference target
Maybe, but XML tools are also just superior to JSON counterparts. XPath is fantastic, and so is XSD and XSLT. I also quite like the integration with .NET.
My general experience with JSON as a configuration language has been sad. It's a step back from XML in a lot of ways.
Re: Xee: A Modern XPath and XSLT Engine in Rust
#229Earlier quoted context omitted.
Maybe one reason is its verbosity for small everyday tasks, like config files or when representing arrays. If xml allowed empty tags there probably would be no need for json.
Empty tag as in ?
That's a bit confusing to me, I don't understand. I think that type of tagging can be ambiguous. Just to suggest a better construct:
Now, that's not perfect, I would even describe it as minimalist, but I hope it sets you in the right direction!
Re: Xee: A Modern XPath and XSLT Engine in Rust
#230Earlier quoted context omitted.
interrsting. I find the signal/noise ratio of XML really bad. what I really dread in XML though is that XML only has idref/id standardized, and no path references. so without tool support you can't navigate to a reference target. which turns XML into the "binary" format for GUI tools.
> so without tool support you can't navigate to a reference target Maybe, but XML tools are also just superior to JSON counterparts. XPath is fantastic, and so is XSD and XSLT. I also quite like the integration with .NET. My general experience with JSON as a configuration language has been sad. It's a step back from XML in a lot of ways.
yes, XML is very mature, and fun if you have access to advanced tools.
however most oss builds on libxml which is stuck in xslt 1 and xpath 2 iirc...
I recently stumbled upon James Clark's youngest brainchild the ballerina language.
https://en.wikipedia.org/wiki/James_Clark_(programmer)#Caree...