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] | [Elist Home]

Subject: RE: DOCBOOK-APPS: Question about the ENTITY references

> I'm using version (Unicode).
> I will report it to XMetaL support and see what happens...

Good luck. Ours was incident number "SQ|1577|3" if you'd like to reference it. 
> Are you still using XMetaL?

I use emacs. Our other writers use a combination of XMetaL and emacs--they'll use XMetaL to compose and often use emacs/nsgmls to validate (see the first problem in the list below). We also stopped trying to do anything complicated with entities. We share content with a poor man's version of xinclude, so we avoid the entity problem in xmetal (but buy ourselves other problems in doing so). I should say that I really like the idea of XMetaL and in the right circumstances it could be the right tool. I know there are docbook users who are happy with it. If you get emacs+psgml mode set up right, it gives you lots of help regarding what elements and attributes are valid, inserting entities, etc. Writing with all those tags in your face just takes some getting used to. Couple emacs with a browser preview using css or msxml, and it's not so bad tho. 

Here are some other things I noticed with XMetaL. Some are bugs, some are 'features' or lack thereof. I reported a few of them to XMetaL, but gave up after a while when nothing seemed to come of it. All are based on 2.1. I haven't evaluated 3.x yet.

* Crashes when you try to validate an invalid doc (I've got a test case that will make it crash; this usually is coupled complicated use of entities). What's really bad about this one is that by default XMetaL valdates when you try to save. So writers would hit save, only to have XMetaL crash and take their work with it.
* Slow with big docs. Very slow if you don't let it pretty print the xml.
* Even if you don't let it pretty print the xml (i.e. you tell it to "preserve space"), it still makes some whitespace changes to the xml, making a simple diff using cvs not so useful.
* Quirks like removing the doctype randomly.
* Fails to find nested comments when validating (and allows the writer to put in nested comments even in the views that are supposed to restrict you to what's allowed). 
* Can't view document as a whole (if the document is broken up into file entities, you have to click through to see the contents of the file--even then, you're in trouble if you try to go more than one level deep). Therefore you can't do a global spell check or search and replace easily from the tool. 
* Can't open a document fragment and associate it with a parent document (like you can with psgml mode's <!-- sgml-parent-document: "../foo.xml" -->
* WSYIWYG table editing is limited. If you insert a column into an existing table, it fails to renumber the existing colspecs. The table looks fine in XMetaL, but when you generate a pdf, it's garbage.
* Doesn't fully support OASIS sgml catalog files (I've got a test case for this too if you want it. This one is frustrating when combined with the problem you originally noticed, since catalog files might have gotten you around it).
* Sometimes it just starts crashing all the time. When this happens, delete the .rlx file (compiled version of the dtd). 
* Gives you no help (what markup is valid here etc.) in 'plain text view'
* 'insert entity' feature very limited.

> Have you ever used the browser preview succesfully? Once you have made
> changes to the document the only thing you get are errors. I 
> cannot believe
> that these kind of errors are in XMetaL...

I've seen it work once or twice, but on every occasion it wouldn't work if you left that preview mode and tried to go back. I've had better luck just putting in a <?xml-stylesheet type="text/xsl" href="..."?> at the top of the doc and dragging it into IE with MSXML installed. Still, MSXML itself is a little flaky. 


> Thanks,
> Simon.
> -----Original Message-----
> From: David Cramer [mailto:dcramer@broadjump.com]
> Sent: vrijdag 1 november 2002 16:40
> To: Kraa de Simon; docbook-apps@lists.oasis-open.org
> Subject: RE: DOCBOOK-APPS: Question about the ENTITY references
> Not. This is one of XMetaL's many limitations. Attached is a 
> test case I
> provided XMetaL support long ago. Out of curiosity, what 
> version of XMetaL
> are you using? I was working with 2.1 when I reported the 
> problem. They're
> response was basically "don't do that."
> David
> > -----Original Message-----
> > From: Kraa de Simon [mailto:Simon.de.Kraa@services.fujitsu.com]
> > Sent: Friday, November 01, 2002 2:44 AM
> > To: 'docbook-apps@lists.oasis-open.org'
> > Subject: DOCBOOK-APPS: Question about the ENTITY references
> > 
> > 
> > Hello,
> > 
> > I have a question about the ENTITY references.
> > 
> > Part of the TDG directory structure:
> > 
> > ./book.xml
> > ./bookbody.xml
> > ./ch00.xml
> > ./entities/content.ent
> > 
> > In bookbody.xml the reference to "chapter 00" is:
> > 
> > &ch00;
> > 
> > In entities/content.ent all entities are referenced by 
> ../ch00.xml but
> > shouldn't this be ./ch00.xml?
> > 
> > Because the bookbody.xml and ch00.xml file are on the same level and
> > ch00.xml is referenced from within bookbody.xml?
> > 
> > <!ENTITY ch00 SYSTEM "../ch00.xml">
> > 
> > The XML editor that I use (XMetaL) cannot find the file 
> > ../ch00.xml and when
> > I think about it I think he is right...
> > 
> > Or not?
> > 
> > 

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

Powered by eList eXpress LLC