- From: BR Chrisman <brchrisman@gmail.com>
- Date: Mon, 9 Jan 2023 08:47:43 -0800
- To: ixml <public-ixml@w3.org>
- Message-ID: <CAN4=B2nUyg8+4YPYNES-vBA9G5_kU0Gzt_JAVhtsOQp2BQ6xbw@mail.gmail.com>
At this point I'm in two boats: 1) I'm trying to figure out ixml in general and where I can apply it. I've got this nagging brain-loop that I'll be able to use it for really cool stuff once I've got it figured out, 2) I have had a long standing wish that I could view/use/manipulate an alternative xpath structure composed in xml (ie, so that all pieces of the xpath expression are individually addressable/queryable like attributes and text nodes) ie, if I could preprocess and xslt stylesheet and wherever there's an @select attribute or @match attribute, place a parsed structure underneath it in its own namespace, I'd be able to rationalize a bit about the elements I'm going to be processing with each template. I'm not sure that makes sense on a re-read.. so here's a not-remotely-suggestive example.. maybe a super simple case would be: <xsl:template match="foo"/> and I'd like to see that as: <xsl:template match="foo"> <ixmlxpath:expression> <ixmlxpath:context-child-element name="foo"/> </ixmlxpath:expression> </xsl:template> With that kind of thing, I'd be able to preprocess my templates that operate on 'foo' elements without having to say things like "awkwardly half-parse this xpath expression and see if it references foo in an obvious way". Does this question make sense, and does iXML make efforts in that direction potentially fruitful for my purposes, or am I barking up the wrong tree?
Received on Monday, 9 January 2023 16:48:07 UTC