You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2003/02/06 00:45:54 UTC
Xinclude and (in)validation
The "Developing with Avalon" docs use XInclude to add author
information, by taking it from a common author dir.
Example:
<?xml version="1.0" standalone="no"?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.1//EN"
"docbookx.dtd">
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xml:base="context://content/xdocs/developing/">
<chapterinfo>
<authorgroup>
<xi:xinclude href="../authors/hammant.xml"/>
</authorgroup>
</chapterinfo>
... etc
So I thought, "hey, not bad, I could put xinclude in the general doc
pipeline and have it available to all xml formats".
Then one thing bit me... validation (or so it seems) :-(
This is what I get:
validate-xdocs:
/jbprojects/ttest/src/documentation/content/xdocs/subdir/conclusion.xml:7:57:
Attribute "xmlns:xi" must be declared for element type "chapter".
/jbprojects/ttest/src/documentation/content/xdocs/subdir/conclusion.xml:7:57:
Attribute "xml:base" must be declared for element type "chapter".
/jbprojects/ttest/src/documentation/content/xdocs/subdir/conclusion.xml:10:53:
Element type "xi:xinclude" must be declared.
/jbprojects/ttest/src/documentation/content/xdocs/subdir/conclusion.xml:11:19:
The content of element type "authorgroup" must match
"(author|editor|collab|corpa
uthor|othercredit)+".
/jbprojects/ttest/src/documentation/content/xdocs/subdir/conclusion.xml:31:16:
The content of element type "footnote" must match
"(calloutlist|glosslist|itemize
dlist|orderedlist|segmentedlist|simplelist|variablelist|literallayout|programlis
ting|programlistingco|screen|screenco|screenshot|synopsis|cmdsynopsis|funcsynops
is|classsynopsis|fieldsynopsis|constructorsynopsis|destructorsynopsis|methodsyno
psis|formalpara|para|simpara|address|blockquote|graphic|graphicco|mediaobject|me
diaobjectco|informalequation|informalexample|informalfigure|informaltable)+".
BUILD FAILED
file://C:/jbprojects/xml-apache/xml-forrest/build/dist/shbat/forrest.build.xml:774:
C:\jbprojects\ttest\src\documentation\content\xdocs\subdir\conclusion.xml
is not a valid XML document.
What should I do now? %-|
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Xinclude and (in)validation
Posted by Steven Noels <st...@outerthought.org>.
Stefano Mazzocchi wrote:
> Just be prepared.
We (Bruno & I) briefly exchanged two words about this, trying to find
some reason to get this out of the way. When work is done on the next
iteration of xReporter, we might as well give the XNI XInclude thingy
which Joerg suggested a go (I know, this should be discussed on
cocoon-dev/xml-commons, will move there when it becomes more than just
some freewheeling thoughts).
Now, there exist already an XInclude Transformer in Cocoon. If we add
the XNI XInclude thingy onto the start of the pipeline, and someone
injects other XInclude declarations into the stream using some XSLT
later on, which should be processed by the XInclude Transformer, there
is a chance for a mismatch between the features & functionalities of
both XInclude-providing implementations.
XNI XSLT XI Transformer
XML+XInclude ------> XML proper ------> XML+XInclude ------> XML
So we must be absolutely sure both implementations work in the same way.
Food for thought.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Xinclude and (in)validation
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
> How the heck is xinclude to work in the real world with validation?
welcome to the world of stupid non-infoset-orthogonal validation languages!
DTDs work as long as you don't deal with namespaced content. DTDs
validate monodimensional infosets. Namespaces add dimensionality and
DTDs were not designed to cope with that.
XMLSchema partially solves the job, but it's still an
non-infoset-orthogonal validation language, so you have pre and post
schema infosets.
RelagNG is the only serious validation language out there and being
totally infoset-orthogonal, validation can (and must) be placed at a
different stage than parsing (as we are doing in cocoon).
The concept of parsing+validation is a thing of the SGML past.
The future is pipeline-based SoC-oriented infoset-orthogonal and
namespace-aware validation and RelaxNG is the *ONLY* validation language
that does so.
Just be prepared.
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
Re: Xinclude and (in)validation
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Jeff Turner wrote:
> Problem is, whatever tool does the xinclude preprocessing will need to
> use a parser, and when that parser encounters the DOCTYPE declaration it
> will try to validate the XML :)
Use a non-validating parser, like AElfred, or tell Xerces
not to validate.
> That is, unless the xinclude tool uses XNI directly, or fiddles with the
> bytestream before and after parsing:
IIRC someone already hooked an XInclude processor into a recent Xerces
using XNI so that it kicks in before validating.
This seems to be a cleaner solution than hacking the DocBook DTD,
and it will alos work for xdocs, XHTML, whatever, at the hopefully
acceptable cost of being locked into using a single XML parser.
Perhaps someone should
1. Read the Xerces docs
2. Ask the CyberNeko maintainer
3. Ask on the Xerces list for support.
> I think the best solution is to modify the DTD to allow xi:include. The
> Docbook book has some info on this process:
This is akward, and I don't think you can really get xi:include
*everywhere*. An people *will* ultimately put an xi:include
somewhere where the DTD forbids it.
> Even the latest version of Docbook has declared SVG, MathML
> and HTML forms in the DTD, rather than abandon DTDs altogether.
You'll note that processing the full DocBook DTD already uses
a significant amount of the total processing time.
J.Pietschmann
Re: Xinclude and (in)validation
Posted by Steven Noels <st...@outerthought.org>.
Nicola Ken Barozzi wrote:
> Anyway, the problem of having a single big file without chunking is
> still a problem. Do you think we should keep a single file (maybe split
> with entities) and chunk it dynamically or make a "book" by binding
> different files?
What about the paginating transformer? I never worked with it, and I
know it still has some issues, who might have been solved to do
http://www.xume.be/ - but I could bug these guys to contribute patches.
Looking at that document, you need both:
- splitting up in entities (or xincluded fragments for easy editing)
- chunk it up in dices for easier web consumption
- during this chunking process, have access to the overall tree of the
document to generate tocs & x-references
I know this doesn't help you, but at least you won't find yourself alone
now. :-)
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Xinclude and (in)validation
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote, On 10/02/2003 17.40:
> Nicola Ken Barozzi wrote:
>
>>
>> Stefano Mazzocchi wrote, On 10/02/2003 14.17:
>> ...
>>
>>> Can't you pass the docbook dtd into some jclark's tool to generate
>>> directly relaxng, then validate using that? not a quick hack, I know,
>>> but that would solve your problems now and forever.
>>
>> Errr, they already have an alpha RelaxNG grammar of Docbook4.2.
>> But does RelaxNG include the fragments of the xinclude before
>> validating? If not, it's a half-validation...
>
>
> You should validate *after* the xinclusion not before. What's the point
> of validating before inclusion?
That's the point. Xerces does not perform xinclude. Thus it doesn't
validate (xi is not in the DTD, and as you say it doesn't make sense).
So if RelaxNG is the solution, it has to do the inclusion. Does it? If
not, why do you suggest it?
%-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Xinclude and (in)validation
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Stefano Mazzocchi wrote, On 10/02/2003 14.17:
> ...
>
>> Can't you pass the docbook dtd into some jclark's tool to generate
>> directly relaxng, then validate using that? not a quick hack, I know,
>> but that would solve your problems now and forever.
>
>
> Errr, they already have an alpha RelaxNG grammar of Docbook4.2.
> But does RelaxNG include the fragments of the xinclude before
> validating? If not, it's a half-validation...
You should validate *after* the xinclusion not before. What's the point
of validating before inclusion?
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
Re: Xinclude and (in)validation
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote, On 10/02/2003 14.17:
...
> Can't you pass the docbook dtd into some jclark's tool to generate
> directly relaxng, then validate using that? not a quick hack, I know,
> but that would solve your problems now and forever.
Errr, they already have an alpha RelaxNG grammar of Docbook4.2.
But does RelaxNG include the fragments of the xinclude before
validating? If not, it's a half-validation...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Xinclude and (in)validation
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
>
>
> Jeff Turner wrote, On 10/02/2003 13.16:
>
>>
>> For Avalon you could just use xinclude, and disable validation for the
>> relevant page:
>>
>> forrest.validate.xdocs.excludes=index.xml
>
>
> Yeah, it sucks but I might as well do it.
> Bleah :-P
Can't you pass the docbook dtd into some jclark's tool to generate
directly relaxng, then validate using that? not a quick hack, I know,
but that would solve your problems now and forever.
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
Re: Xinclude and (in)validation
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote, On 10/02/2003 13.16:
>
> For Avalon you could just use xinclude, and disable validation for the
> relevant page:
>
> forrest.validate.xdocs.excludes=index.xml
Yeah, it sucks but I might as well do it.
Bleah :-P
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Xinclude and (in)validation
Posted by Jeff Turner <je...@apache.org>.
On Mon, Feb 10, 2003 at 12:32:38PM +0100, Nicola Ken Barozzi wrote:
>
>
> Nicola Ken Barozzi wrote, On 07/02/2003 23.31:
> >
> >
> >J.Pietschmann wrote, On 07/02/2003 23.28:
> >
> >>Nicola Ken Barozzi wrote:
> >>
> >>>Problem: one big file :-(
> >>>
> >>>Now, how do I split it?
> >>
> >>Plain old XML entities? :-)
> >
> >
> ><banging the head>
> >Sometimes the simple way is just too near to see ;-)
>
> And then when you try it it hits you harder than the initial bangign ;-)
>
> Gosh, I tried that too but failed *miserably*.
>
> This is the reason [1]:
> "
> The basic problem is that in order to put a SYSTEM entity
> declaration in a chapter file to include its sections, the
> chapter file must have a DOCTYPE declaration to permit
> adding an internal subset. But then the chapter file is
> referenced as a SYSTEM entity from the book file.
> Then you find out that a file referenced as a
> SYSTEM entity cannot have a DOCTYPE declaration according
> to the XML spec, and parsers will report errors if it
> does. This "feature" is a serious barrier to doing
> modular doc like you want.
Didn't know about that. Ew..
> "
>
> So I'm back to square 1 it seems.
For Avalon you could just use xinclude, and disable validation for the
relevant page:
forrest.validate.xdocs.excludes=index.xml
--Jeff
> I'm back to xinclude. I want to use it also in site.xml, to gather
> snippets from online common versions (and fallback if it doesn't find
> them). We have to put xinclude before validation. I also tried mixinf
> DTDs but it was a mess (since xincludes can happen everywhere in the
> document), and i'd have to do it for all our DTDs.
>
> Can anyone give me some pointer to how it can be done in Xerces?
> (yes, XNI, I know, I need more concrete tips)
>
> Anyway, I'm pursuing another path ATM, that of using book.xml as a
> binder for a single-page view of the book.
>
> *sigh*
>
>
> [1] http://sources.redhat.com/ml/docbook-apps/2002-q4/msg00339.html
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
Re: Xinclude and (in)validation
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Nicola Ken Barozzi wrote, On 07/02/2003 23.31:
>
>
> J.Pietschmann wrote, On 07/02/2003 23.28:
>
>> Nicola Ken Barozzi wrote:
>>
>>> Problem: one big file :-(
>>>
>>> Now, how do I split it?
>>
>> Plain old XML entities? :-)
>
>
> <banging the head>
> Sometimes the simple way is just too near to see ;-)
And then when you try it it hits you harder than the initial bangign ;-)
Gosh, I tried that too but failed *miserably*.
This is the reason [1]:
"
The basic problem is that in order to put a SYSTEM entity
declaration in a chapter file to include its sections, the
chapter file must have a DOCTYPE declaration to permit
adding an internal subset. But then the chapter file is
referenced as a SYSTEM entity from the book file.
Then you find out that a file referenced as a
SYSTEM entity cannot have a DOCTYPE declaration according
to the XML spec, and parsers will report errors if it
does. This "feature" is a serious barrier to doing
modular doc like you want.
"
So I'm back to square 1 it seems.
I'm back to xinclude. I want to use it also in site.xml, to gather
snippets from online common versions (and fallback if it doesn't find
them). We have to put xinclude before validation. I also tried mixinf
DTDs but it was a mess (since xincludes can happen everywhere in the
document), and i'd have to do it for all our DTDs.
Can anyone give me some pointer to how it can be done in Xerces?
(yes, XNI, I know, I need more concrete tips)
Anyway, I'm pursuing another path ATM, that of using book.xml as a
binder for a single-page view of the book.
*sigh*
[1] http://sources.redhat.com/ml/docbook-apps/2002-q4/msg00339.html
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Xinclude and (in)validation
Posted by Nicola Ken Barozzi <ni...@apache.org>.
J.Pietschmann wrote, On 07/02/2003 23.28:
> Nicola Ken Barozzi wrote:
>
>> Problem: one big file :-(
>>
>> Now, how do I split it?
>
>
> Plain old XML entities? :-)
<banging the head>
Sometimes the simple way is just too near to see ;-)
Anyway, the problem of having a single big file without chunking is
still a problem. Do you think we should keep a single file (maybe split
with entities) and chunk it dynamically or make a "book" by binding
different files?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Xinclude and (in)validation
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Nicola Ken Barozzi wrote:
> Problem: one big file :-(
>
> Now, how do I split it?
Plain old XML entities? :-)
J.Pietschmann
Re: Xinclude and (in)validation
Posted by Steven Noels <st...@outerthought.org>.
Nicola Ken Barozzi wrote:
> So, I happily got the problem I reported, and then looked for an
> Xinclude solution for validation. No real luck, I cannot find easy
> resources to get it going. Yes, I'm sure that xinclude before validation
> is the way to go, but then it seems too much hassle for a small use case
> ATM.
When googling on 'xni' and 'xinclude', it seems almost like we are the
only ones talking about this - how encouraging :-)
Would http://xincluder.sourceforge.net/ be of any help? From Elliotte
Harold, so it shouldn't be too bad, but it supports only an old pre-WD
of the spec. But wait: it's LGPL code :-|
Fun, fun.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Xinclude and (in)validation
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote, On 07/02/2003 15.10:
> On Thu, Feb 06, 2003 at 09:10:07AM +0100, Nicola Ken Barozzi wrote:
>>Well, I think that including xinclude ;-) in the DTDs is a reasonable
>>thing, and one of the possible solutions. The fact is that I don't like
>>much fiddleing with other DTDs, and since users might want to make their
>>own DTD /and/ pretend to have xinclude working, maybe a pre-xinclude
>>step would ease things.
>
> Looks like Joerg is right, and the XNI XInclude thingy is the best
> immediate solution.
>
>>Dunno, both seem ok... I'll see if I can do something with a
>>pre-xinclude. Maybe it will just slow down things and be a mess or it
>>will be simply to hard to do, I don't wnat to spend too much time on it,
>>if it takes too much, I'll include it in the DTD.
>
> +1
>
>>BTW, is everyone ok if I put xinclude in the processing (just to be sure)?
>
> +1
And now I'm back to square 1.
What I really want to do is use the "developing with avalon" book in
Forrest. As it happens, it's written in docbook, and split out in
different files. The main fila has a bunch of xincludes for the
chapters, and the chapters have xincludes of the authors.
So, I happily got the problem I reported, and then looked for an
Xinclude solution for validation. No real luck, I cannot find easy
resources to get it going. Yes, I'm sure that xinclude before validation
is the way to go, but then it seems too much hassle for a small use case
ATM.
Fiddling with the DTD always makes me uneasy, so I said "heck with it,
let's include them all in a single page".
Ok, put them all in a single page, and it renders. Not perfect - well
much less than perfect - but it renders not bad in Forrest.
Problem: one big file :-(
Now, how do I split it?
Should it be paginated? If so, when does paginating occur and how does
the left menu interact?
Should it be split in different files, and have them aggregated in a
"book.xml"?
If I use book.xml, I loose the initial declarations in a docbook file.
So the book format as it is now is inadeguate to define "books", it's
too rudimentary. Maybe enhancing that a bit and making chapters
different files?
Oh boy...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Xinclude and (in)validation
Posted by Jeff Turner <je...@apache.org>.
On Thu, Feb 06, 2003 at 09:10:07AM +0100, Nicola Ken Barozzi wrote:
>
>
> Jeff Turner wrote, On 06/02/2003 2.34:
> >On Thu, Feb 06, 2003 at 01:20:28AM +0100, Nicola Ken Barozzi wrote:
> >
> >>Replying myself. Found a doc that explains it.
> >>http://www.xml.com/pub/a/2002/07/31/xinclude.html?page=2
> >
> >...
>
> ...
> >>Possibility: plug in an xinclude step before the validation. There is an
> >>xinclude task somewhere, if not we can make it.
> >
> >Problem is, whatever tool does the xinclude preprocessing will need to
> >use a parser, and when that parser encounters the DOCTYPE declaration it
> >will try to validate the XML :)
>
> Even non-validating? IIRC when you have a DTD, it always reads it, but
> for entities. Validation is a further step.
Ah yes, I'm talking rubbish. Non-validating should work.
> >That is, unless the xinclude tool uses XNI directly, or fiddles with the
> >bytestream before and after parsing:
> >
> >http://doctypechanger.sourceforge.net/
> >
> >I think the best solution is to modify the DTD to allow xi:include. The
> >Docbook book has some info on this process:
> >
> >http://docbook.org/tdg/en/html/ch05.html
> >
> >I don't think there are any better solutions, so long as we're hanging
> >onto DTDs. Even the latest version of Docbook has declared SVG, MathML
> >and HTML forms in the DTD, rather than abandon DTDs altogether.
>
> Ahhh.
>
> Well, I think that including xinclude ;-) in the DTDs is a reasonable
> thing, and one of the possible solutions. The fact is that I don't like
> much fiddleing with other DTDs, and since users might want to make their
> own DTD /and/ pretend to have xinclude working, maybe a pre-xinclude
> step would ease things.
Looks like Joerg is right, and the XNI XInclude thingy is the best
immediate solution.
> Dunno, both seem ok... I'll see if I can do something with a
> pre-xinclude. Maybe it will just slow down things and be a mess or it
> will be simply to hard to do, I don't wnat to spend too much time on it,
> if it takes too much, I'll include it in the DTD.
+1
> BTW, is everyone ok if I put xinclude in the processing (just to be sure)?
+1
--Jeff
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
Re: Xinclude and (in)validation
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote, On 06/02/2003 2.34:
> On Thu, Feb 06, 2003 at 01:20:28AM +0100, Nicola Ken Barozzi wrote:
>
>>Replying myself. Found a doc that explains it.
>>http://www.xml.com/pub/a/2002/07/31/xinclude.html?page=2
>
> ...
...
>>Possibility: plug in an xinclude step before the validation. There is an
>>xinclude task somewhere, if not we can make it.
>
> Problem is, whatever tool does the xinclude preprocessing will need to
> use a parser, and when that parser encounters the DOCTYPE declaration it
> will try to validate the XML :)
Even non-validating? IIRC when you have a DTD, it always reads it, but
for entities. Validation is a further step.
> That is, unless the xinclude tool uses XNI directly, or fiddles with the
> bytestream before and after parsing:
>
> http://doctypechanger.sourceforge.net/
>
> I think the best solution is to modify the DTD to allow xi:include. The
> Docbook book has some info on this process:
>
> http://docbook.org/tdg/en/html/ch05.html
>
> I don't think there are any better solutions, so long as we're hanging
> onto DTDs. Even the latest version of Docbook has declared SVG, MathML
> and HTML forms in the DTD, rather than abandon DTDs altogether.
Ahhh.
Well, I think that including xinclude ;-) in the DTDs is a reasonable
thing, and one of the possible solutions. The fact is that I don't like
much fiddleing with other DTDs, and since users might want to make their
own DTD /and/ pretend to have xinclude working, maybe a pre-xinclude
step would ease things.
Dunno, both seem ok... I'll see if I can do something with a
pre-xinclude. Maybe it will just slow down things and be a mess or it
will be simply to hard to do, I don't wnat to spend too much time on it,
if it takes too much, I'll include it in the DTD.
BTW, is everyone ok if I put xinclude in the processing (just to be sure)?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Xinclude and (in)validation
Posted by Jeff Turner <je...@apache.org>.
On Thu, Feb 06, 2003 at 01:20:28AM +0100, Nicola Ken Barozzi wrote:
> Replying myself. Found a doc that explains it.
> http://www.xml.com/pub/a/2002/07/31/xinclude.html?page=2
...
> > How the heck is
> >xinclude to work in the real world with validation?
>
> Relevant answer in the above cited doc:
> "
> One of the most common questions about XInclude is how inclusion
> interacts with validation, XSL transformation, and other processes that
> may be applied to an XML document. The short answer is that it doesn't.
> XInclusion is not part of any other XML process. It is a separate step
> which you may or may not perform when and where it is useful to you.
>
> For example, consider validation against a schema. A document can be
> validated before inclusion, after inclusion, or both. If you validate
> the document before the xi:include elements are replaced, then the
> schema has to declare the xi:include elements just like it would declare
> any other element. If you validate the document after the xi:include
> elements are replaced, then the schema has to declare the replacement
> elements. Inclusion and validation are separate, orthogonal processes
> that can be performed in any order which is convenient in the local
> environment.
> "
>
> So, since I want xinclude functionality to be present, also because I
> imagine that we can xinclude parts of site.xml to generate consistent
> multi-project sites, how are we going to solve this?
>
> Possibility: plug in an xinclude step before the validation. There is an
> xinclude task somewhere, if not we can make it.
Problem is, whatever tool does the xinclude preprocessing will need to
use a parser, and when that parser encounters the DOCTYPE declaration it
will try to validate the XML :)
That is, unless the xinclude tool uses XNI directly, or fiddles with the
bytestream before and after parsing:
http://doctypechanger.sourceforge.net/
I think the best solution is to modify the DTD to allow xi:include. The
Docbook book has some info on this process:
http://docbook.org/tdg/en/html/ch05.html
I don't think there are any better solutions, so long as we're hanging
onto DTDs. Even the latest version of Docbook has declared SVG, MathML
and HTML forms in the DTD, rather than abandon DTDs altogether.
--Jeff
> Dunno, I'm going to sleep now, maybe tomorrow it will be clearer 8-)
>
Re: Xinclude and (in)validation
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Replying myself. Found a doc that explains it.
http://www.xml.com/pub/a/2002/07/31/xinclude.html?page=2
Nicola Ken Barozzi wrote, On 06/02/2003 1.07:
>
> J.Pietschmann wrote, On 06/02/2003 1.00:
>
>> Nicola Ken Barozzi wrote:
>>
>>> What should I do now? %-|
>>
>>
>> Plug in the validation processor after the XInclude processor.
>> Didn't someone just announce such a compenent on the Cocoon
>> list?
>
>
> Hmmm... we are doing validation as a step before even Cocoon being
> called. I don't think it's even correct to validate a document at every
> call, it should be done beforehand IMHO.
>
> That said, and looking at your suggestion, it seems that I'm starting to
> understand why some talk about validation being toed to a processing
> definition...
>
> The fact is: is the xml fragment I posted valid xml?
Nope, it doesn't validate.
> How the heck is
> xinclude to work in the real world with validation?
Relevant answer in the above cited doc:
"
One of the most common questions about XInclude is how inclusion
interacts with validation, XSL transformation, and other processes that
may be applied to an XML document. The short answer is that it doesn't.
XInclusion is not part of any other XML process. It is a separate step
which you may or may not perform when and where it is useful to you.
For example, consider validation against a schema. A document can be
validated before inclusion, after inclusion, or both. If you validate
the document before the xi:include elements are replaced, then the
schema has to declare the xi:include elements just like it would declare
any other element. If you validate the document after the xi:include
elements are replaced, then the schema has to declare the replacement
elements. Inclusion and validation are separate, orthogonal processes
that can be performed in any order which is convenient in the local
environment.
"
So, since I want xinclude functionality to be present, also because I
imagine that we can xinclude parts of site.xml to generate consistent
multi-project sites, how are we going to solve this?
Possibility: plug in an xinclude step before the validation. There is an
xinclude task somewhere, if not we can make it.
Dunno, I'm going to sleep now, maybe tomorrow it will be clearer 8-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Xinclude and (in)validation
Posted by Nicola Ken Barozzi <ni...@apache.org>.
J.Pietschmann wrote, On 06/02/2003 1.00:
> Nicola Ken Barozzi wrote:
>
>> What should I do now? %-|
>
> Plug in the validation processor after the XInclude processor.
> Didn't someone just announce such a compenent on the Cocoon
> list?
Hmmm... we are doing validation as a step before even Cocoon being
called. I don't think it's even correct to validate a document at every
call, it should be done beforehand IMHO.
That said, and looking at your suggestion, it seems that I'm starting to
understand why some talk about validation being toed to a processing
definition...
The fact is: is the xml fragment I posted valid xml? How the heck is
xinclude to work in the real world with validation?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Xinclude and (in)validation
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Nicola Ken Barozzi wrote:
> What should I do now? %-|
Plug in the validation processor after the XInclude processor.
Didn't someone just announce such a compenent on the Cocoon
list?
J.Pietschmann