Continuing the XHTML/XML thread, I wrote a function for translating XML into a namespace. It's not perfect yet and doesn't handle attributes, but it is usable for getting a namespace from a (standard-compliant) HTML document.
html
<html>
<body>
<h2>
Hello,
</h2>
<h2>
World!
</h2>
</body>
</html>
⎕JSON Xmln html
{"html":{"body":[{"h2":"Hello,"},{"h2":"World!"}]}}
(Xmln a).html.body.h2
Hello, World!
@finooiigee That's cool. Is there any particular reason why you're wanting to represent trees as a namespace hierarchy instead of some inverted table with depth information or whatnot?
Oops - I meant only <script>. If the content of the script tag contains valid HTML - ⎕XML will parse it, which can create an invalid dom
Barring that you can write fully functional HTML in a XHTML compatible manner
@B.Wilson It is a good question. It shouldn't be too hard to implement . for the usual format of ⎕XML - an inverted table with depth information. Another reason to generate namespaces is that ⎕JSON is a useful intermediary format
@finooiigee ⎕JSON⍠'M' will give you a table with depth info, so you could stay in inverted-table land. I was mostly just wondering if you had a specific problem in hand where hierarchies of namespaces gave you particular ergonomics not afforded by an inverted table.
@dzaima Someone recently asked me if I could hack together a certain prototype Android app, and I thought it'd be fun to do it in APL. I'm aware that your APL implementation has an android app, but is it relatively easy to do Java interop for GUI element hooks and the like? I'll probably want to look at your code, but just wanted to get a quick sanity check before diving in.
@RikedyP For 181 rows of (⎕XML) - from a 9000 character HTML document, it takes 4ms to convert to a namespace - which although small is still surprising to me. It should scale linearly - and I think it could be written in a much more performant way.
I'll look into abacus
@B.Wilson namespaces are easier to use, and lead to more straight-forward code. But it's not too significant. I wouldn't mind writing 'h2' mdot 'body' mdot html
@B.Wilson dzaima/APL doesn't provide anything for allowing to invoke Java things from APL, so you'd be stuck doing most things in Java. It does have a Processing integration, which'd allow you to draw rectangles & circles & stuff, but no native UI stuff
@finooiigee Hrm. Not sure I agree. In some limited cases, like your html.body.h2 example, the syntax looks nice, but even ignoring the fact that it throws away the ordering information on sibling nodes, the ergonomics of semantic operations over the whole tree can be pretty bad.
For example, how would you capitalize all your h2 elements? Or what about grabbing the content of any div that has a particular annotation?
Using named-column tables, seems to put all these problems within reach of fast, normal APL operations. E.g.
{p[⍵]←⍺[⍺⍸⍵]}/⊢∘⊂⌸d⊣p←⍳≢⊃d n v t←↓⍉⎕json⍠'M'⊢'{...}'
Then your (Xmnl a).html.body.h2 becomes something like n[∪p∘I⊢p∘I⍸n≡¨⊂'h2']≡,⊂'body', or even v/⍨n∘.≡⊂'h2', depending on exactly what you're wanting to say.
IMO, the latter two sentences more directly surface the intent of what you're wanting to do, whereas html.body.h2 doesn't tell me whether you actually really care about h2 being a child of body or whether you are enforcing html to be unique at the top.
