stevenn at outerthought
Feb 14, 2002, 1:20 PM
Views: 84
Permalink
|
|
[RT] On xml infrastructure work
|
|
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.
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.
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
out-of-the-box.
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.
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 :-)
Regards,
</Steven>
|
[RT] On xml infrastructure work
