forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Pietschmann <>
Subject Re: [RT] Entities in XML docs
Date Sat, 28 Dec 2002 16:33:05 GMT
On Saturday 28 December 2002 16:52, you wrote:
> It has the same problems as <xi:include>, ie requires editing DTDs so
> that nn:replace is recognized.

I'm not sure whether this is an argument: the doc with ${} abbrevs
might be invalid according to the DTD too because of missing
mandatory child elements, unless you restrict the replacement
to pure text, no elements.

The solution is of course to expand the replacements before
validating. At this point the abbreviation syntax doesn't matter.
Ok, this doesn't exactly work out of the box with current tools,
and is certainly bad for DTD directed editors.

If you start relaxing the schema you can allow <xi:include> or
<nn:replace/> as well, in particular if you use a schema language
which allows elements wholesale from a namespace, like XSD
(dunno about RNG). This might even facilitate editor support
for abbreviations.

Can we have a survey on which XML editors people (doc editors)
use, and how much they rely on on-the-fly XML validation repectively
DTD direction of the editor?
I use Emacs+PSGML, and while PSGML is DTD directed, I can insert
any elements without problems, full validation is an external process

As you might have guessed, I usually oppose the creation of new
languages, even (especially!) simple ones like ${} substitution. Every
new language means
- Full spec. BTW your proposal is heavily underspecified. E.g. what is the
  prefix in ${some:ambiguous:stuff}?
- Unexpected interactions with other mechanisms, potential for name
  clashes etc.
- Write a customized toolset.
- Dependency on the availability of said tools in other environments, like
  IDEs, other toolsets etc.
You know, I'm not really a fan of "specification by implementation", look
what happened to the "easy and intuitive" C preprocessor.


View raw message