This is the mail archive of the docbook-apps@lists.oasis-open.org mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: XInclude doesn't validate with xmllint


Yann Dirson <ydirson@altern.org> writes:

> It happens that the following idea just reached my concious mind, so I try
> to followup to the correct thread.
> 
> IIRC the context was about validating documents before or after xinclude
> processing.
> 
> My opinion is still that we need to be able to validate before, and that
> does not prevent to validate after as well.
> 
> There is even a use-case for this.  If the individual XML files do not
> validate (ie. conform to a DTD which has the xinclude elements), then we
> cannot make use of the existing SGML editing tools (psgml comes to my mind
> as one of the most widely used, since its existence even brought some vi
> adepts to launch emacs sometimes).

During the DocBook TC discussion about this, the first thing that came
to mind for me was the "editing use case" -- what users are supposed to
do if:

 * The DTD they're using doesn't contain an xi:include element
 
 - but- 
 
 * They want to take documents containing <xi:include> instances, and
   work with them in a DTD-aware validating editor that does error-
   checking/validation interactively against a DTD as you edit.

In that case, most editing applications will report the <xi:include>
instance as an error -- an invalid/undefined element.

But after listening to Bob's explanation during the the TC discussion, I
realized that even if it were practical to add xi:include to DocBook
(which it's not), it wouldn't be a good idea to do it -- because it's a
problem that should be resolved at the editing-tool level, not at the
DTD level. I think the follow-up message that Bob just posted here a
couple days ago reinforces what he said durin the TC discussion.

XInclude support in editing tools (or in any other XML processing tool)
is something that ideally should be available to users regardless of
what DTD/schema they author with. DTDs/schemas should not have to be
retro-fitted to support XInclude. Even if there were a practical way to
do that, it just wouldn't be the elegant or efficient way to go about
it. It really should be implemented at the tool level instead.

  --Mike

> On Fri, Oct 04, 2002 at 06:41:08AM -0400, Daniel Veillard wrote:
> > > >   But allowing an extra attribute everywhere is quite simpler
> > > > than allowing an extra element everywhere :-)
> > >
> > > "everywhere" is probably too strong, i bet noone wants to use this for
> > > inline elements.
> >
> >   Well, it's hard to predict a priori in what way people are gonna use
> > a relatively new tool, I would not constraint the use case while there
> > have been only little use so far.
> 
> Yes, and IMHO not adding the xinclude elements to the DTD will effectively
> constraint the use case of DocBook.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]