Live data from Hacker News

XSLT – Native, zero-config build system for the Web

github.com

171–180 of 337 posts

Re: XSLT – Native, zero-config build system for the Web

#171

Earlier quoted context omitted.

Old guy here. Agreed- the actual story of web development and JavaScript’s use was much different. HTML was the original standard, not JS. HTML was evolving early on, but the web was much more standard than it was today. Early-mid 1990s web was awesome. HTML served HTTP, and pages used header tags, text, hr, then some backgound color variation and images. CGI in a cgi-bin dir was used for server-side functionality, o…

Though much less awesome was all the Flash, Realplayer and other plugins required.

Realplayer. christ, forgot all about that one.... thanks... frozenface

Re: XSLT – Native, zero-config build system for the Web

#172

Earlier quoted context omitted.

That… has nothing to do with xpath? If your document has namespaces, xpath has to reflect that. You can either tank it or explicitly ignore namespaces by foregoing the shorthands and checking `local-name()`.

Ok. Perhaps 'namespace the query' wasnt quite the right way of explaining it. All I'm saying is, whenever I've used xpath, instead of it looking nice like /*bookstore/*book/*title its been some godawful mess like /*[name()='bookstore']/*[name()='book']/*[name()='title'] ... I guess because they couldn't bear to have it just match on tags as they are in the file and it had to be tethered to some namespace stuff that m…

I don't recall ever needing to do that for unnamespaced tags. Are you sure the issue you're having isn't that the tags have a namespace?

my:book is a different thing from your:book and you generally don't want to accidentally match on both. Keeping them separate is the entire point of namespaces. Same as in any programming language.

Re: XSLT – Native, zero-config build system for the Web

#173

It's sad how the bloat of '00s enterprise XML made the tech seem outdated and drove everyone to 'cleaner' JSON, because things like XSLT and XPath were very mature and solved a lot of the problems we still struggle with in other formats. I'm probably guilty of some of the bad practice: I have fond memories of (ab)using XSLT includes back in the day with PHP stream wrappers to have stuff like ` ` This may be out-of-da…

It's been 84 years but I still miss some of the "basics" of XML in JSON - a proper standards organization, for one. But things like schemas were (or, felt like) so much better defined in XML land, and it took nearly a decade for JSON land to catch up. Last thing I really did with XML was a technology called EXI, a transfer method that converted an XML document into a compressed binary data stream. Because translating…

That data transform thing xslt could do was so cool. You could twist it into emitting just about any other format and XML was the top layer. You want it in tab delimited yaml. Feed it the right style sheet and there you go. Other system wants CSV. Sure thing different style sheet and there you go.

For a transport tech XML was OK. Just wasted 20% of your bandwidth on being a text encoding. Plus wrapping your head around those style sheets was a mind twister. Not surprised people despise it. As it has the ability to be wickedly complex for no real reason.

Re: XSLT – Native, zero-config build system for the Web

#174
To show how wild things got w/ XML and XSLT in the early 2000s, I worked for a company that built an ASIC to parse XML at wire speed and process XSLT natively in the chip - because the anticipated future of the internet was all XML/XSLT. Intel bought the company and the guts made their way into the SSE accelerators.

Re: XSLT – Native, zero-config build system for the Web

#175

Earlier quoted context omitted.

That… has nothing to do with xpath? If your document has namespaces, xpath has to reflect that. You can either tank it or explicitly ignore namespaces by foregoing the shorthands and checking `local-name()`.

Ok. Perhaps 'namespace the query' wasnt quite the right way of explaining it. All I'm saying is, whenever I've used xpath, instead of it looking nice like /*bookstore/*book/*title its been some godawful mess like /*[name()='bookstore']/*[name()='book']/*[name()='title'] ... I guess because they couldn't bear to have it just match on tags as they are in the file and it had to be tethered to some namespace stuff that m…

> the tags as they are in the file

Is not actually relevant and is not an information the average XML processor even receives. If the file uses a default namespace (xmlns), then the elements are namespaced, and anything processing the XML has to either properly handle namespaces or explicitly ignore namespaces.

> A lot of XML is ad-hoc without a namespace defined anywhere

If the element is not namespaced xpath does not require a prefix, you just write

    //bookstore/book/title

Re: XSLT – Native, zero-config build system for the Web

#177

Sometimes I wish we could have kept XML alive alongside JSON.. I miss the comments, CDATA etc, especially when you have to serialize complex state. I know there are alternatives to JSON like YAML but I felt XML was better than YAML. We adopted JSON for its simplicity but tried to retrofit schema and other things that made XML complex. Like we kind of reinvented JSON Schema, and ended up like what XSD did decades ago…

I just had to explain to some newbies that SOAP is a protocol with rigid rules; REST is an architectural style with flexibility. The latter means that you have to work and document really well and consumers of the API need tools like Postman etc. to be even able to use the API. With SOAP, you get most of that for free.

Postman is just a terrible GUI for making HTTP requests. Using a REST API can be as simple as `curl https://api.github.com/repos/torvalds/linux`, and you can even open that link in a browser. SOAP requires sending a ton of XML [0] - it is not very usable without a dedicated SOAP-aware tool.

[0] https://en.wikipedia.org/wiki/SOAP#Example_message_(encapsul...

Re: XSLT – Native, zero-config build system for the Web

#178

People love to complain about verbosity of XML, and it looks complicated from a distance, but I love how I can create a good file format based on XML, validate with a DTD and format with XSLT if I need to make it very human readable. XML is the C++ of text based file formats if you ask me. It's mature, batteries included, powerful and can be used with any language, if you prefer. Like old and mature languages with th…

Why DTD and not XSD?

Re: XSLT – Native, zero-config build system for the Web

#179
I'm old enough to remember when Google released AJAXSLT in 2005. It was a JS implementation of XSLT so that you could consistently use XSLT in the browser.

The funny thing is that the concept of AJAX was fairly new at the time, and so for them it made sense that the future of "fat" web pages (that's the term they use in their doc) was to use AJAX to download XML and transform it. But then people quickly learned that if you could just use JS to generate content, why bother with XML at all?

Back in 2005 I was evaluating some web framework concepts from R&D at the company I worked, and they were still very much in an XML mindset. I remember they created an HTML table widget that loaded XML documents and used XPATH to select content to render in the cells.

Re: XSLT – Native, zero-config build system for the Web

#180

Earlier quoted context omitted.

Though much less awesome was all the Flash, Realplayer and other plugins required.

Realplayer. christ, forgot all about that one.... thanks... frozenface

ah the feelings. those were the times
Post reply on HN