Hello, Yes, on Mac computers the schema cannot be validated with the default stack size due to a StackOverflowError. With one megabyte for the stack, that is -Xss1m the validation is successful. Regards, Sorin George Cristian Bina wrote:

Dear Syd,

I am not able to reproduce the problem, both schemas are validated ok and also an instance document. I am testing on a Windows XP but I will have someone testing also on a Mac shortly. In any case, to increase the stack memory you need another switch because both -Xmx and -Xms are related with the heap memory setting the maximum and the start amount, respectively. To set the stack memory you need -Xss, for instance -Xss1024k sets the stack to one megabyte.

Best Regards, George --------------------------------------------------------------------- George Cristian Bina - http://aboutxml.blogspot.com/ <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com

Syd Bauman wrote:

...

I know this has been discussed on this list before, and I apologize for not just looking through the archives myself -- my excuse is that I'm on the road, due to teach using oXygen in a matter of hours, and all h#!! is breaking loose.

I have generated some schemas that oXygen can't use to validate an instance; and, I note, oXygen can't validate them. In both cases it sufferes a stack overflow. I am using the current release and have set -Xmx999M and -Xms64M at the end of my oxygenMac.sh file (which is how I invoked oXygen).

The schemas can be found at http://bauman.zapto.org/~syd/temp/temi.rnc http://bauman.zapto.org/~syd/temp/temi.rng

I tried to validate the schemas w/o using oXygen. `jing` complained that the version of relaxng.rng that came with oXygen does not have a <start> element, but it says that temi.rng is valid against the relaxng.rnc that came with nxml-mode. `rnv` agrees on both counts.

(I've also tried several diffferent combinations of TEI modules to see what would and would not cause a stack overflow, but do not have a definitive answer yet.)

Can anyone provide any useful info here?

Hello, Yes, the stack overflow error is coming from the Java virtual machine and usually the cause is an infinite recursion which is obviously not solved with an increase in the stack size. The rare cases when a larger stack size would be enough cannot be distinguished by the programmer when it is signalled by the JVM so I think the proper place to let the user know is the user manual. We will add a note to the section about XML document validation. Regards, Sorin Syd Bauman wrote:

Now, for my education: where in the documentation should I have looked to find that information? It's pretty important, and so should be pretty obvious. (Best would be to have it in the stack overflow message itself, but I presume that's coming from Java, and you don't have control over it.)