Subject: Re: [xsl] character entities From: Joerg Pietschmann <joerg.pietschmann@xxxxxx> Date: Fri, 23 Nov 2001 15:03:09 +0100 |
David Carlisle <davidc@xxxxxxxxx> wrote: > [I'm not sure we're still on topic for this list, but anyway..] Mentioning XSL/XPath a few times should suffice :-) > > two pass approach. > Yes but then basically you are in the same situation as with entities: > You have an expanded document and it isn't necessarily easy to construct > an unexpanded one from a stylesheet. First, you can choose whether to expand or not. Second, you can leave the referencing nodes in the tree and only expand them by adding the referenced forest as cildren. This will of course work better if you use diffentiated semantic references where references cannot occur everywhere whith everything as content, so they are much easier to integrate in your XPaths. In the case of general references, you might be able to insert dummy reference nodes, so that every ancestor::*[position() mod 2=1] of a non-reference element is a reference element (or whatever else is appropriate). > > You can use nag:ref-formula, nag:ref-constraint etc. > I could, but it would still make listing all the arguments used in > constraints more complicated than the current > select="//constraints//arg" I know, therefore i use *always* an indirection: <document> <constraintdef name="foo-constraint">...</constraintdef> <whatever> ... <constraintref name="foo-constraint"/> ... </whatever> </document> You obviously can still use select="//constraintdef//args" for global queries and select="key('constraint',$name)//args" for more local ones. I admit that editing it will be more of a pain, you'll probably have to extensively customize your editor at least for fast switching between references and their definition. An editor which will show a XSLT transformed result in real time would be a real boon. (I'm currently wrestling with XMetal...) > and apart from impressing Jeni... You'd impress me too, a real achievement :-) > > If the references become somewhat standardized, you should be able to > > put this logic into reusable templates. > It's easier to say "reusable templates" than define what it means. Ok, i should have omitted the buzzword. I meant that i have templates for pulling in stuff across references instead of handling everything inline. These templates could be quite general, i.e. i have some templates handling a whole bunch of different reference elements. > Also I'd have to go outside XSLT 1.0 (not > that that necessarily matters) as if the current template goes > select="../param/constraints" to select all the constraints on sibling > parameters, then there is _nothing_ a template can do to create that > node set, as templates don't create nodesets. I wonder why Dimitre has not jumped onto this, as that's a prime example for using generic templates. Write a somewhat general frame for using recursive templates to collect the nodes you want to have into a node-set and invoke the desired functionality in the recursive template via the generic template indirection. (might impress Dimitre too :-) > It's like saying how do you mix a w3c Schema definition with a relax NG > one. If you choose to define something in two ways, it's up to you to > make sure they are compatible. Or more simply just define it one way. The point was: If you have entities, you'll *have* to use a DTD. If you actually want to use XSchema (or some other structure definition language), perhaps because you like XSchema types, you can get dependencies you don't want to have. A non-validating parser might ignore entity definitions, a validating one will want to have a structure definition, which duplicates information from your schema. You may find a parser which expands all entities without doing validating, but there is no standardized way you can rely on for using "the best of both worlds". > that's fine but currently DTD's offer a lot more functionality than > schemas, so this won't happen soon. Oops, what functionality beside defining entities for physical structuring? I'm not sure whether XSchema's has features like conditional sections, but i think much of the modularisation and customization of the structure definition could also be achieved with redefinitions and references to definitions in other namespaces. In fact, i'd like to have this *now*. My DTD and XSL grew somewhat ugly *because* DTDs are not namespace aware, and you have only the choice to define an element as ANY or explicitely state all 100+ allowed elements instead of allowing a bunch of elements from a namespace. (Discussing the dependencies between XML structure and the XSL for processing it would make an interesting thread...) > There are lots of XML editors out > there with context sensitive operations driven by dtds. No doubt people > are working to try to do something similar with schemas, but is it there > yet? There was a time without XSLT processors. Of course Schema driven editors will take a lot more time to appear and to work even remotely reliable, since schemas are new, much more complex than DTD and almost impossible to handle without tools. But poeple will continue to complain about missing the possibility to define an attribute as a date (so that the editor can open a calendar widget for input assistance), therefore schema driven editors will ultimately appear. :-) Regards J.Pietschmann XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] character entities, David Carlisle | Thread | Re: [xsl] character entities, David Carlisle |
Re: [xsl] generating broken html?, Francis Norton | Date | AW: [xsl] WG: folder-trouble, Arend Vogtländer |
Month |