> From: Steven Noels [mailto:firstname.lastname@example.org]
^ - do you mean Konstantin? (this must be our unpredictable Exchange
server that swaps over first and last names as he likes)
> > > From: Steven Noels [mailto:email@example.com]
> > >
> > > At best, XML Schemas are commonly considered to be primarly
> > data- and
> > > not document-focused. Furthermore, the spec is crap, and the
> > > implementations are only able to make some sense of this crap.
> > >
> > > Sorry for being so frank, but after teaching some courses on XML
> > > Schemas, I'm quite convinced it is a horribly bloated language.
> > But you can't disagree that XSD has also some very useful
> > features. And
> > having a visual tool like XML Spy (Schema editor), I even
> > haven't to know
> > the XSD language details to create usable schemas. And the
> > other good thing
> > about the XSD is that it's XML and you can use XSLT to
> > display it as you
> > like.
> That's the theory, I fear. There's a number of constructs in the spec
> which can be written down in 2 or more different ways, meaning:
> - XMLSpy generates the XML syntax Altova thinks of being
> "best practice"
> - writing XSLT to process XML Schemas can be very hard because of the
> difference between the semantics of the model and how you
> write it down
> See http://www.amazon.co.uk/exec/obidos/ASIN/1861005474/ which has a
> chapter from Jeni Tennison about XSLT & XML Schemas.
> So yes, you can use "XMLSpy XML Schema" and XSLT - but that's
> not "true
> W3C XML Schema", I fear.
Yes, I am agree with almost all the above.
> > E.g. all Cocoon transformers, logicsheets and some generators
> > should have
> > their corresponding DTDs or schemas and they should be linked
> > from the docs.
> > I can see a lot more good features with XSD: filtering by
> > element types,
> > sorting, getting attributes for an element. I even think that
> > some parts of
> > docs can be autogenerated from XSD using the comments from it.
> Yep, these are very good use cases, if only there was some
> real interest
> in actually maintaining these XML-described interfaces... Developers
> prefer sticking to source code interface contracts rather than XML
> grammars, I fear. Also, I'm not really a supporter of autogenerated
> documentation, but that's my personal pessimism, I guess :-)
Having Schemas first and implementation next for all the
transformers/logicsheets would allow to keep in sync either the source code
and the docs. I can imagine something like this in a transformer docs:
And a pipeline like:
A stylesheet can generate a table like: "element | description | attributes"
and even have jumps to details like:
Am I dreaming too much? ;)
> > What do you think?
> > Regards,
> > Konstantin
> > P.S. Hope to finish i18n doc rewriting in v11 format this
> > weekend and will
> > try to come up with a more real world sample page for
> > documentation menu.
> That would be cool - ready to do some work based upon it!