You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Ovidiu Predescu <ov...@cup.hp.com> on 2002/05/17 20:43:42 UTC

Re: draft howto dtd

On Fri, 17 May 2002 08:30:01 -0500, "Ivelin Ivanov" <iv...@apache.org> wrote:

> 
> Do you guys thing its time to switch the DTD to XML Schema ?
> Xalan supports XML Schema validation and I've used it in production for a
> while now.

Dropping DTD would probably be a bad idea IMO, since not all the XML
processors support XML Schema. I prefer to use Saxon with its builtin
XML parser or with Crimson because they're smaller and faster than
xerces.

Also most of the free XML editors don't support XML Schema yet,
including my favorite one Xemacs.

Greetings,
-- 
Ovidiu Predescu <ov...@cup.hp.com>

>>> I'm in the job market again, check out my resume and qualifications at:
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)


> ----- Original Message -----
> From: "Diana Shannon" <te...@mac.com>
> To: <fo...@xml.apache.org>
> Sent: Thursday, May 16, 2002 7:37 AM
> Subject: Re: draft howto dtd
> 
> 
> > Steven,
> >
> > > 1) too few optional elements
> > >
> > >    - overview, audience, purpose and prerequisites (or is it really
> > > prerequesites?) should be optional, I guess...
> >
> > I don't understand. A howto should be more structured than your average
> > document page. I consider those elements vital and user-friendly. They
> > are only a few sentences. Why make them optional? It creates more work
> > others.
> >
> > >    - furthermore, I believe there will be confusion between
> > > header>abstract, overview and purpose, especially if they all need to be
> > > filled in
> >
> > Ok, I considered that too. However, abstract is optional in the document
> > dtd, and I wanted it required. I wasn't sure how to override that. Any
> > suggestions?
> >
> > >    - reference to faqs elements, but not reusing the one defined in
> > > faq-v11.dtd
> > Good point. I'll add that.
> >
> > > 3) Obviously, I don't like the s2/title attributes... :-)
> > >
> > > This is a nice example of the tedious result of including a
> > > hierarchy/nesting indication in an element name...
> > >
> > > I'd much prefer this:
> > >
> > >     <!ELEMENT steps (section | %blocks;)+ >
> > >     <!ATTLIST steps %common.att;>
> >
> > Not all how-tos will fit perfectly into the step by step model. I had
> > this originally, but I took it out.
> >
> > > On a related note: why provide title elems/attrs with the various parts
> > > of your DTD... the meaning of the parts (and the title using which they
> > > should be rendered) is pretty clear and perhaps is something which can
> > > be automated using a stylesheet, I believe:
> > >
> > > <xsl:template match="steps">
> > >   <section>
> > >     <title>Steps</title>
> > >     <xsl:apply-templates/>
> > >   </section>
> > > </xsl:template>
> >
> > I wasn't sure if I should allow readers to write their own section
> > titles. Most how-tos do... My titles are too generic, and I don't really
> > like that.
> >
> > >> 1. I think the header element contains a lot of useful
> > >> cms-related info.
> > >> Perhaps version can be used to imply status:
> > >> draft/release/revision. I'm
> > >> not sure of its precise meaning with code, but perhaps
> > >> "draft" document
> > >> versions could have a value less than 1, etc.
> > >
> > > We could provide use a list of possible attribute values for that, too -
> > > so that not everybody starts to invent his own classification.
> >
> > Great.
> >
> > >> 5. Steve, I wonder if you're going to dislike the way I'm treating
> > >> titles (as attributes) in each howto part. I just found it a little
> > >> simpler to implement this way. Feel free to revise, in
> > >> anticipation of
> > >> your v11 work.
> > >
> > > That's Steven ;-)
> >
> > Ooops. Really sorry ;).
> >
> > > See above - will you update, or will I do? Decision to be made is
> > > integration with the new doc-v11 or not.
> >
> > Let me try another pass, and then you can refine it as necessary. I'm
> > still rather confused, v10 or v11? Please, I just don't want the doc-v11
> > decision to delay the howto effort. I have put warnings on the how to
> > write a how-to, etc. pages (which are based on v10), so potential
> > authors are alerted that things will change.
> >
> > Diana
> >
> 

Re: draft howto dtd

Posted by "J.Pietschmann" <j3...@yahoo.de>.
David Crossley wrote:
> I fully agree that going away from DTDs at this time is not a good
> idea. To me, the XML Schema looks too cumbersome, especially
> for our documentation needs.

While I don't like XSchema all that much and agree that it is
very bloated, I don't see what makes it too cumbersome for
documentation. You don't have to use all the fine details in
an XSchema for docs.
It could be an argument that DTDs are easier to read. But then
why do people look into DTDs? They want to know the structure
of the document they want to write. In case of an XSchema, you
can generate a nice HTML visualizing the allowed structure,
even better than a DTD. You can have multiple visualizations
from different points of view. Only the document structure
developers really have to bother with XSchema syntax and
semantics. And of course the validation tools :-)

J.Pietschmann




Re: draft howto dtd

Posted by David Crossley <cr...@indexgeo.com.au>.
Ovidiu Predescu wrote:
> Ivelin Ivanov wrote:
> 
> > Do you guys thing its time to switch the DTD to XML Schema ?
> > Xalan supports XML Schema validation and I've used it in
> > production for a while now.
> 
> Dropping DTD would probably be a bad idea IMO, since not all the XML
> processors support XML Schema. I prefer to use Saxon with its builtin
> XML parser or with Crimson because they're smaller and faster than
> xerces.
> 
> Also most of the free XML editors don't support XML Schema yet,
> including my favorite one Xemacs.

I fully agree that going away from DTDs at this time is not a good
idea. To me, the XML Schema looks too cumbersome, especially
for our documentation needs.

I do agree that DTDs are not quite powerful enough to do full
XML and content validation. However there are better tools
than XSD for that. Back in February we had a couple of short
threads about RELAX NG ...
http://marc.theaimsgroup.com/?l=forrest-dev&m=101431895118300
http://marc.theaimsgroup.com/?l=forrest-dev&m=101431895118321

Konstantin said that he liked XSD because it could be presented
using XSLT. There are tools in the abovementioned threads to
convert a DTD into an XML form, so you could achieve the
same thing. The generated grammar would need to be cleaned
up, like all autogenerated stuff.
--David