forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject Re: [RT] Entities in XML docs
Date Sun, 29 Dec 2002 03:47:34 GMT
On Sat, Dec 28, 2002 at 05:33:05PM +0100, Joerg Pietschmann wrote:
> 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.

That was Stefano's suggestion: that we do text-only expansion for now
(element expansion is still possible with xinclude), and when we migrate
to a decent schema language we can think about removing the text-only

I don't fully understand why we can't give users the option to shoot
themselves in the foot by including elements, but implementation-wise
there's little difference (two different InputModules).

> 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?

vim + xmllint

> I use Emacs+PSGML, and while PSGML is DTD directed, I can insert
> any elements without problems, full validation is an external process
> anyway.
> 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}?

I guess with InputModules, 'some' is the prefix.

> - Unexpected interactions with other mechanisms, potential for name
>   clashes etc.

Practically I don't think this will be a problem:

 - The ${*:*} syntax is sufficiently unique to avoid most conflicts.
 - If 'scheme' in ${scheme:variable} is not a known scheme, the string
   isn't replaced.
 - If 'variable' in ${scheme:variable} isn't defined, the string isn't
 - If ${scheme:variable} IS meaningful to the user, then they can escape
   it with $${scheme:variable}, or some other syntax.

> - Write a customized toolset.


> - Dependency on the availability of said tools in other environments, like
>   IDEs, other toolsets etc.

My editor doesn't do anything special with C #includes either.

> You know, I'm not really a fan of "specification by implementation", look
> what happened to the "easy and intuitive" C preprocessor.

Just like the C preprocessor, It is an opt-in solution to a practical


> J.Pietschmann

View raw message