Mailing-List: contact forrest-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: forrest-dev@xml.apache.org
Date: Sun, 29 Dec 2002 14:47:34 +1100
From: Jeff Turner <jefft@apache.org>
To: forrest-dev@xml.apache.org
Subject: Re: [RT] Entities in XML docs
Message-ID: <20021229034734.GA1235@expresso.localdomain>
Mail-Followup-To: forrest-dev@xml.apache.org
References: <20021227134332.GA3868@expresso.localdomain>
 <200212281517560.SM00297@there> <20021228155221.GD3310@expresso.localdomain>
 <200212281736925.SM00297@there>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200212281736925.SM00297@there>
User-Agent: Mutt/1.4i

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
restriction.

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
   replaced.
 - 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
problem.

--Jeff

> J.Pietschmann