> I was just wondering if you'd given any thought to trying to make > trang more powerful? It'd be the sweetest thing *ever* if it could > turn the DocBook RELAX NG grammar[1] into XSD.
It's certainly something I've thought about in the past. There's a long list (just for the XSD output part) here: http://code.google.com/p/jing-trang/source/browse/trunk/mod/convert-to-xsd/todo.txt My thoughts recently have been: - it seems like an awfully long list, - some of them seem really hard and - I don't know how useful each of them would be. It would be really helpful to have multiple bug reports (in the issue tracker) of the form: - here's a small bit of RELAX NG (preferably in the compact syntax) - here's the XSD that trang currently generates - this is bad because... - the XSD I would like trang to generate is... - fixing this would be slightly/somewhat/very useful to me Once I have a bunch of these I can allocate a big block of time to get back up to speed on both the XSD output module and XSD itself, and come up with a concrete plan for what to fix. There might be the odd thing that can be fixed easily, but I suspect making substantial progress here will require a sustained effort. One general problem is that there's a tension between: - preserving the information that's relevant to a human author but not to a schema processor (e.g. preserving all RELAX NG pattern definitions), which requires a representation close to the surface syntax - intelligent handling of deep differences in the capabilities of RELAX NG and XSD, which requires a representation close to the semantic structure (e.g. one that simplifies out some of the RELAX NG definitions) If we look at RELAX NG to XSD conversion, then there are two use cases. - If you're using RELAX NG as your source format, then I guess the latter is more important; you would need trang to always generate a correct XSD schema that accepts any XML document that the RELAX NG schema accepts, even if what it generates is not pretty. - On the other hand, if you're doing a one-time conversion of a schema into XSD, which you are subsequently going to maintain as XSD, you might give more importance to the former; you might prefer to fix things up manually whenever trang cannot preserver the RELAX NG semantics. I'm guessing that the first use case is the more important one. James
