3 ms·

Agreed. It's ridiculous that .NET still doesn't have XPath 2 support after so many years. I really wish they'd hire a PM with enterprise experience, as they see

Agreed. It's ridiculous that .NET still doesn't have XPath 2 support after so many years. I really wish they'd hire a PM with enterprise experience, as they seem heavily focused on public facing web technologies e.g. the new native JSON serializer has all kinds of weird limitations based on 'security risks' that don't actually exist outside of public facing websites.

int_19h 5y ago
XSLT/XPath/XQuery 2.0+ has little first party support in general, in all programming ecosystems that I can think of. I think the problem is that it's all much more complicated than the originals, and meanwhile XML has become legacy tech - not that it's going away anytime soon, but it's kind of like the COBOL of data.
- ryanjshaw 5y ago
  .NET caters to the enterprise, or at least it used to. It's irrelevant what other ecosystems prioritise. What makes you say that XML is legacy tech? In the financial industry XML is used extensively. For example, FpML underpins a massive part of global finance, and it is a regularly updated standard. COBOL has been superceded by other languages; I'm not aware of any technology that can replace the XML-based FpML schema.
  - phillipcarter 5y ago
    > .NET caters to the enterprise, or at least it used to. .NET is for enterprises who don't treat tech as frozen in time the instant it gets adopted now.
  - int_19h 5y ago
    "Legacy" is perhaps not the best word to describe it; what I mean is that new technologies, protocols etc being developed generally avoid XML. So new products and libraries don't have to deal with it that much. And older ones are already written relying on older versions of XPath etc, so there isn't a strong incentive to upgrade there. Even if we're talking about libraries that are still getting updated to reflect changes in the standards. The comparison with COBOL is fairly straightforward. There's still plenty of COBOL code running in prod around the world - but you don't see much clamoring to add new features to it. Oh, and .NET doesn't really cater specifically to the enterprise these days. It was definitely true back when it was first released (remember all the emphasis on SOAP?), and for a while after. But .NET Core was an attempt to broaden its scope, and it very much succeeded. I should add that I'm not particularly happy about this. I did a lot of XSLT 2.0 and XQuery 2.0 back in mid-00s, using Saxon, and I still miss many aspects of it. The new "best thing" seems to be JSON, but, while the syntax is certainly nicer, the tooling ecosystem around it is still nowhere near what we had back then.

int_19h 5y ago

XSLT/XPath/XQuery 2.0+ has little first party support in general, in all programming ecosystems that I can think of. I think the problem is that it's all much more complicated than the originals, and meanwhile XML has become legacy tech - not that it's going away anytime soon, but it's kind of like the COBOL of data.

ryanjshaw 5y ago
.NET caters to the enterprise, or at least it used to. It's irrelevant what other ecosystems prioritise. What makes you say that XML is legacy tech? In the financial industry XML is used extensively. For example, FpML underpins a massive part of global finance, and it is a regularly updated standard. COBOL has been superceded by other languages; I'm not aware of any technology that can replace the XML-based FpML schema.
- phillipcarter 5y ago
  > .NET caters to the enterprise, or at least it used to. .NET is for enterprises who don't treat tech as frozen in time the instant it gets adopted now.
- int_19h 5y ago
  "Legacy" is perhaps not the best word to describe it; what I mean is that new technologies, protocols etc being developed generally avoid XML. So new products and libraries don't have to deal with it that much. And older ones are already written relying on older versions of XPath etc, so there isn't a strong incentive to upgrade there. Even if we're talking about libraries that are still getting updated to reflect changes in the standards. The comparison with COBOL is fairly straightforward. There's still plenty of COBOL code running in prod around the world - but you don't see much clamoring to add new features to it. Oh, and .NET doesn't really cater specifically to the enterprise these days. It was definitely true back when it was first released (remember all the emphasis on SOAP?), and for a while after. But .NET Core was an attempt to broaden its scope, and it very much succeeded. I should add that I'm not particularly happy about this. I did a lot of XSLT 2.0 and XQuery 2.0 back in mid-00s, using Saxon, and I still miss many aspects of it. The new "best thing" seems to be JSON, but, while the syntax is certainly nicer, the tooling ecosystem around it is still nowhere near what we had back then.