OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [docbook-apps] Preserving entities during SGML to XML transformation


Mike,

"hiding" the internal entities only may indeed be a good work-around, 
though I'd need to implement a way that will survive a sgml2xml 
conversion. I guess I'll be doing that now though. To be honest though, 
I'm really close at attempting to write my own sgml2xml converter, since 
I can hardly stand the resulting format. Neither can some of the tools. 
Some of the output needs to be post-processed, in order to be useable 
for, for example, po2xml. Then again, that may just be a bug in po2xml? 
Is there any way to keep the format "as is", i.e. using the same 
indentation and the same newlines at the same places, not putting, apart 
from the nl-in-tag, everything in one (or a few) line(s)? Or is there 
any other sgml to xml converter that would do that?

Thanks for the help!

Bernd

Michael Smith wrote:

>Bernd Groh <bgroh@redhat.com> writes:
>
>  
>
>>when trying to convert larger projects from sgml to xml, using sgml2xml 
>>(osx), trying to not resolve internal entities, using 
>>-xno-expand-internal, I do get a Segmentation fault. This only happens 
>>in larger projects, and if I enable no-expand-internal. Did anyone ever 
>>come across this, is there a fix, or can anyone suggest another tool for 
>>the conversion of larger projects, where neither internal, nor external 
>>entities are to be resolved?
>>    
>>
>
>I have never run into that problem with sgml2xml/osx, but for
>dealing with the issue of preventing entities from getting
>expanded, I wrote a simple Perl script, called "cloak", that
>hides/unhides entities (and some other things).
>
>I run it as a pre-processing step to feeding the docs to other
>tools, so that entities in them end up being hidden to the eyes of
>any XML/SGML parser looking at the docs.  I then run it again as a
>post-processing step, to unhide the entities and other things that
>it has "cloaked".
>
>I have put a copy of the script is here:
>
>  http://docbook.sourceforge.net/outgoing/cloak
>
>And I have also now checked it into the "contrib" area of the
>DocBook project CVS repository. So you may also be able to get it
>from the project ViewCVS interface:
>
>  http://cvs.sourceforge.net/viewcvs.py/docbook/contrib/tools/
>
>But that lags behind the real CVS repository by several hours. So
>it may not yet be there by the time you look.
>
>  --Mike
>
>  
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]