Subject: Re: [xsl] Switching off character entity resolution in XSL From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx> Date: Wed, 04 Feb 2004 14:09:49 -0500 |
...... My strategy is to live with the fact that the parser has carried out all the entity mappings, and to use a "mappings" document containing entries like this:
<char> <name>Delta</name> <value>Δ</value> <unicode>0394</unicode> <description>Delta Dec:916 </description> <mapping>[capital Delta]</mapping> <!--U0394 /Delta capital Delta, Greek --> </char>
Yes, it is slow and clumsy, and yes, it does use the deprecated disable-output-escaping, but it does work ...
I'm afraid the simple answer is the ugly one: just preprocess the entity references with a text editor to read "$#$bull;" instead of "•". No point banging your head against the wall to find something more elegant, it will only give you a headache.
Cheers, Wendell
Richard Light
>Example: >source document contains: • >After transformation: [bull ] (of course, the entity declared >in the DTD is this, i.e. <!ENTITY bull "[bull ]">) >What I would like: • > >I really don't want to go messing with the DTD either, and I really don't >think a parser would like there being unparsed entities within an entity >declaration in a DTD i.e. <!ENTITY bull •> is illegal. > >I realise there is some way of dealing with this with character >substitutions before or after using something like sed, but this isn't >really a great solution, particularly across platforms. Is there any way of >manipulating the output using XSL, or alternatively switching off entity >resolution in the parser? I've played with custom entity resolvers with >Java XML parsers (i.e. resolving URLs for example) but cannot see how this >could be used for external character entities, and also realise there is >some scope for writing a solution in something like JDOM - but what a pain! >That defeats the whole purpose of XSL. I have gotten used to a pretty good >compromise of using Saxon with the Xerces parser and the Norm Walsh entity >resolver classes if that's of any help. > >Either there's a simple solution to this, it's something XML 2.0 (or >whatever is on the horizon) might address (which is no help for me really), >I'm on the wrong mailing list or I should just resort back to ("the good >ol' days of" - yes, sarcasm) Omnimark which was really good at "unparsing" >entities. I'm sure others experience similar problems so hopefully the >first option is the right one (i.e. easy ?). > >Thanks very much, >Alan Hynes. > > > > > > > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list >
-- Richard Light SGML/XML and Museum Information Consultancy richard@xxxxxxxxxxxxxxxxx
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
====================================================================== Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Switching off character e, Richard Light | Thread | RE: [xsl] Switching off character e, Michael Kay |
[xsl] table header respecting xml s, Rui Alberto L. | Date | Re: [xsl] Node Order and Value dete, scott gabelhart |
Month |