forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Piroumian Konstantin <KPiroum...@protek.com>
Subject RE: draft howto dtd
Date Sat, 18 May 2002 11:50:55 GMT
> From: Steven Noels [mailto:stevenn@outerthought.org] 
> 
> Piroumian,

        ^ - 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:stevenn@outerthought.org]
> > >
> > > 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:

<section>
  <title>Markup</title>
  <cinclude:include href="cocoon:/dtd/i18n.xsd" />
</section>

And a pipeline like:
<match pattern="*.xsd">
	<generate src="{1}.xsd" />
	<transform src="xsd2table.xsl" />
	<serialize />
</match>

A stylesheet can generate a table like: "element | description | attributes"
and even have jumps to details like:
- Element
	- Description
	[- Attributes
		- Descriptions]*

Am I dreaming too much? ;)

Konstantin

> 
> >
> > 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!
> 
> </Steven>
> 

Mime
View raw message