crossley at indexgeo
Feb 15, 2002, 12:19 AM
Post #2 of 7
Steven Noels wrote:
> Looks like I have found a nice new project to grok my teeth upon :-)
> Going through the list archives so far, I saw some discussions whether
> to use old-fashioned DTD's vs RelaxNG or other schema languages. Being a
> primarly document-oriented and old-school-SGML user, I believe this all
> boils down to tools support.
> Sure RelaxNG somehow supports the best of both world between DTD's and
> XML Schemas, i.e. primarly document-oriented structures with the strong
> datatyping inherited from the XML Schema world, but I still have pretty
> strong feelings when it comes upon deciding what schema language to
> enforce upon users of your grammars.
Looking at RELAX NG some more, i see that one of its primary
purposes is structural and content validation. I gather that we
would still need the Apache DTDs for other reasons. The
previous discussion was not really looking for a replacement
to DTDs, rather looking for a reliable way to do XML validation.
My aim is to have a validation ability in both Cocoon and
Forrest that ensures that the XML documentation and the
configuration files are reliable.
I feel that your discussion here is about a separate issue,
which is another important part of an "xml infrastructure".
It may be that we need different schema for different purposes.
As they can be completely external to the document instances,
it is OK to have multiple schema. So i do not think that we
need to "enforce" any particlar schema language.
> I believe the primary kind of 'users' for Forrest will be document
> creators and editors, which means we should opt for a schema language
> that is supported by tools for these particular tasks. In my daily life,
> floating between creating XML documents for further processing by the
> Java/XML tools of the Apache project, I find myself in a multitool
> environment, switching between Softquad XMetal, XMLSpy and Excelon
> Stylus for creating XML documents and XSLT stylesheets, using MSXML and
> Xerces/Xalan for commandline validation and operations on my XML stuff,
> and finally doing production runs on my XML collection using
> Cocoon(/CLI), the Ant Style task etc etc...
> I'm pretty sure not everybody wants to load its laptop/workstation with
> a miriad of commercial/opensource tools just for playing around with XML
> documents, but I believe we should think about the tools in the document
> creation process when deciding on the infrastructure that Forrest will
> provide (enforce?) upon its users. Some of them will stick to trusty old
> Textpad/Emacs/nameyourbrand, others like to work with more WYSIWYG XML
> editors such as XMetal, and yet others perhaps would like Forrest to
> come with an XML editing environment preconfigured for the grammars and
> tasks at hand. The decision to use catalogs (and their XML variants)
> clearly comes from a validation and transportability perspective, and
> catalogs are supported by a lot of commercial XML tools, too.
Yes, i agree with all that you say ... and yes, "provide"
rather than "enforce".
> As I stated in my previous mail, I'd be pretty happy to do some work on
> providing XMetal-specific configuration files, but I was thinking also
> of preparing a non-commercial XML editor for inclusion or supporting
> More precisely, I was thinking about Pollo
> (http://pollo.sourceforge.net/), which has its own little schema
> language but I know that its author (being an ex-colleague) has some
> tools to translate between DTD's and the Pollo schema language. I've
> been using Pollo quite often when teaching XML & Cocoon courses, it is
> pretty configurable and really well build and it comes with an MIT
> license. Doing the Pollo configuration work, we can offer our users (the
> various XML Apache project teams) with a 'website' and documentation
> editing tool if they have no access to other (commercial) tools and want
> to work with an XML-aware environment. Doing the XMetal configuration
> job, we do the same for .... euh ... people like me who like a spell
> checker and stuff when writing (XML) documents.
It would be excellent to see support for various tools.
This would further encourage reliable XML documents.
I will investigate Pollo further - i tried a while ago but turned
busy with other stuff.
> Besides all these vague arguments, I just wanted to say that I plan to
> do some work on Forrest since the idea behind it is quite appealing for
> a dochead like me :-)
I suspected that we have a lot in common, and now i see
that we are both docheads :-)