[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Regular expression functions (Was: Re: comments on
Hi Peter, > >> If a "matcher" explicitly returns a tree structure you could view it as > >> sending the results to the output document. Thus, wrapping it in > >> a variable > >> would allow you to manipulate the results in a natural (XSL at > >> least) way: > >> > >> <xsl:variable name="gunk"> > >> <xsl:apply-templates > >> select-regexp=":fancy-number:\w:fancy-number:" /> > >> </xsl:variable> > >> <xsl:value-of select="$gunk[2]/*[2]"/> > >> > >> (The template might actually be doing a "match-regexp", but to keep > things > >> concise let's pretend the example is complete :-). > >> > >> This seems to minimize the need to invent new stuff? Adding a similar > form > >> of regexp qualifier/attribute to copy and copy-of would seem to handle > all > >> general cases, no? > > > > it does indeed, some questions/2nd thoughts > > in which context would this be usefull? > > on what inputstring would the regex be matched? the value of . (current > > node/list/string)? it's serialized version? > > I guess one could slice that three ways: 1) match against the value of the > current node; 2) more usefully: as a selector on the entire sub tree of > nodes from the current context, by their values; 3) probably a little > strange to try and figure out: use the regexp to in some way select the > nodes by applying the regexp to some form of xpath representation. > > Complete serialization would seem to make little sense since one > wants to be > able to select nodes out of the mess? But that's an assumption > on my part, > it seems you want to be able to select substrings.... > the process was (derived from omnimark times) called 'uptransforming' as adding markup into areas where it's missing or badly placed (like loads of HTML, where it's cluthering what it's really about)... this often is easier by regexing accross node boundaries (using your lingo: considering the whole mess (including the tags) at once, rather then only the submess inside a node :-)) other hand, I understand this kinda breaks with the more common xslt feeling (where the incoming stream can't be more messy then xml allows :-)) have to admit the cross-node-boundary-thing would more often be seen as a fancy anything (-that-can- be-called-text) to xml _parser_ then a needed feature of a _transformer_ ... still... allowing users to assemble (never mind how) a markup-containing string they want to parse into a nodeset to handle in the xslt engine probably _is_ considered as a sensible feature, in which case having a kindof regex-sheet-driven _parser_ that can be asked from the xslt process to return it's nodes wouldn't be so different. -marc= XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|