I’ve been writing a alpine style framework based on xpath & its really impressive. I’m even trying to store client-side state as XML gasp and you can do stuff like count(//user) to query the amount of users in your system, seems worth investigating.
I am completely with you, but I am just profoundly entertained to see all these XPath and XML stories popping up. We had full-blown databases that used XML for querying back in the early 2000s, and they were awesome for document-based workflows in a way that things like Mongo can’t even imagine (for exactly the kinds of reasons you’re mentioning). Sadly, they were billed as something that should replace RDBMSes (lolno), and things like Mongo and CouchDB ended up moving the document-store model over to JSON. History doesn’t repeat, but it definitely rhymes.
That said, while I’d be quite happy to see an XML and XPath renaissance, please count me the hell out if anyone starts waxing rhapsodic about SOAP.
Not that I’d bother mentioning in 2023, sadly. My experience with these was back in ~2005-2008 or so, so any thoughts I had on particulars would be comically out-of-date. It’s worth noting that PostgreSQL, MSSQL, and I believe Oracle all have solid XML support built-in anyway (see e.g. https://www.postgresql.org/docs/current/functions-xml.html), so I don’t know that I’d reach for a pure XML doc store these days even if I knew a particularly good one.
ACID compliant so commit/rollback semantic works across the horizontally scaled nodes.
Their indexes are ‘column-oriented’ memory stores (in my opinion).
They (at least used to, from my memory of 10 or so years ago) support temporal data management (data that as both business and system timestamps).
etc.
I am with XML all the time, from its „hype“ through its „outsider“ years :-)
Is someone interested in XPath and XML in the commandline? There are much more XML-related examples and it allows you using XPath even with other formats (JSON, YAML, CBOR, HTML, MIME, INI, ASN.1…).
Having picked up a book on XSL and XPath from the clearance section of a bookstore in ~2006 ended up getting me a job in 2009. I was a diamond in the rough because I came into the job knowing something that the team generally had to teach, and expect little productivity for the first several months because, well, XSL and XPath are hard in practice.
It’s now been seven years since I last worked in that stack. I don’t miss it much, but it has it tactical applications.
I used XML for storing in postgres around 15 years ago. With hindsight, I was probably over-engineering the solution but what it gave you at the time was a way to store structured but schemaless data but in a way that postgres could query so that a DBA or someone writing a report could write correct queries.
A year or so before that I actually was using XSLT and xml includes to essentially do ESI in the browser before I knew what ESI was.
The disclaimer here is that I am a fan of the admittedly unpopular and flawed XML and XPath but I’m glad to see some people also seeing the silver lining. One advantage XML + XPath had was that XPath was effectively considered part of proper XML support and all mature XML systems have a compliant XPath library readily available. This is in contrast to JSON which has a handful of competing object path systems that all have varying levels of popularity and standardization. It is nice to have something that works and is consistently available over a wasteland of competing standards and none of them shipped with your parsing libraries.
One advantage XML + XPath had was that XPath was effectively considered part of proper XML support and all mature XML systems have a compliant XPath library readily available.
I dunno - in Python for example, the xpath support is pretty terrible - you need lxml to get anything resembling a full xpath implementation. And XML namespace support is shoddy or at the very least painful in about any language.
XML went a little too far in what it was trying to do, but it was a valiant effort and I think we’d better learn from its mistakes and more importantly, what it got right. With things like JSON it seems we’re doomed to reinvent it in worse ways.
I’ve been writing a alpine style framework based on xpath & its really impressive. I’m even trying to store client-side state as XML gasp and you can do stuff like
count(//user)to query the amount of users in your system, seems worth investigating.I am completely with you, but I am just profoundly entertained to see all these XPath and XML stories popping up. We had full-blown databases that used XML for querying back in the early 2000s, and they were awesome for document-based workflows in a way that things like Mongo can’t even imagine (for exactly the kinds of reasons you’re mentioning). Sadly, they were billed as something that should replace RDBMSes (lolno), and things like Mongo and CouchDB ended up moving the document-store model over to JSON. History doesn’t repeat, but it definitely rhymes.
That said, while I’d be quite happy to see an XML and XPath renaissance, please count me the hell out if anyone starts waxing rhapsodic about SOAP.
I was just thinking that about XML databases, any decent ones I should take a look at?
Not that I’d bother mentioning in 2023, sadly. My experience with these was back in ~2005-2008 or so, so any thoughts I had on particulars would be comically out-of-date. It’s worth noting that PostgreSQL, MSSQL, and I believe Oracle all have solid XML support built-in anyway (see e.g. https://www.postgresql.org/docs/current/functions-xml.html), so I don’t know that I’d reach for a pure XML doc store these days even if I knew a particularly good one.
if your interests include commercial vendors: MarkLogic
https://www.marklogic.com/product/server/
ACID compliant so commit/rollback semantic works across the horizontally scaled nodes. Their indexes are ‘column-oriented’ memory stores (in my opinion). They (at least used to, from my memory of 10 or so years ago) support temporal data management (data that as both business and system timestamps). etc.
eXist, BaseX, PostgreSQL
I am with XML all the time, from its „hype“ through its „outsider“ years :-)
Is someone interested in XPath and XML in the commandline? There are much more XML-related examples and it allows you using XPath even with other formats (JSON, YAML, CBOR, HTML, MIME, INI, ASN.1…).
Having picked up a book on XSL and XPath from the clearance section of a bookstore in ~2006 ended up getting me a job in 2009. I was a diamond in the rough because I came into the job knowing something that the team generally had to teach, and expect little productivity for the first several months because, well, XSL and XPath are hard in practice.
It’s now been seven years since I last worked in that stack. I don’t miss it much, but it has it tactical applications.
I used XML for storing in postgres around 15 years ago. With hindsight, I was probably over-engineering the solution but what it gave you at the time was a way to store structured but schemaless data but in a way that postgres could query so that a DBA or someone writing a report could write correct queries.
A year or so before that I actually was using XSLT and xml includes to essentially do ESI in the browser before I knew what ESI was.
https://en.wikipedia.org/wiki/Edge_Side_Includes
The disclaimer here is that I am a fan of the admittedly unpopular and flawed XML and XPath but I’m glad to see some people also seeing the silver lining. One advantage XML + XPath had was that XPath was effectively considered part of proper XML support and all mature XML systems have a compliant XPath library readily available. This is in contrast to JSON which has a handful of competing object path systems that all have varying levels of popularity and standardization. It is nice to have something that works and is consistently available over a wasteland of competing standards and none of them shipped with your parsing libraries.
I dunno - in Python for example, the xpath support is pretty terrible - you need lxml to get anything resembling a full xpath implementation. And XML namespace support is shoddy or at the very least painful in about any language.
XML went a little too far in what it was trying to do, but it was a valiant effort and I think we’d better learn from its mistakes and more importantly, what it got right. With things like JSON it seems we’re doomed to reinvent it in worse ways.