forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Dixon <...@dixons.org>
Subject Re: xinclude
Date Mon, 11 Sep 2006 12:07:23 GMT
On Mon, 11 Sep 2006, Ross Gardler wrote:

> >>>> A better approach would be to process the XIncludes before validation,
> >>>> stripping off the xlmns:xi attribute from the document element and
> >>>> replacing xi:includes with whatever they resolve to.  This should be
> >>>> cheaper than it might seem: unless the xmlns:xi is present, the
> >>>> document is simply handed on to the validator untouched.
> >>>
> >>> I can't see an easy way of doing this as, in many cases, the included
> >>> content is generated by Forrest. In fact, this would be a problem if the
> >>> parser were doing the includes.
> >>
> >> I am baffled.  How would it be a problem if the parser was doing the
> >> XIncludes?
> >
> > David points out in another message that the validate-xdocs is done
> > prior to Forrest doing any transformations on content, it only validates
> > the *source* documents.

Yes.  Now think carefully about what you are saying.  Validation is
against the DTD, say document-v20.dtd.  This is validation of the source
document.  As it stands, if that source document has any xs:includes in
it, it is rejected by the validator.

What you are saying is that when (some?) source documents are translated
into internal format, Forrest adds xi:includes, and the transformed
documents would not validate. That is, Forrest's internal format is not
compliant with document-v20.dtd.

Forrest DOES NOT VALIDATE the internal format.

Nothing that I have said has anything to do with the internal format.

If Forrest were to turn on XInclusion during the validation process,
this would have no effect whatsoever on internal processing, because
what is being validated is the source document.  It would, however,
remove xi:includes and replace them with what they are referencing,
and then validate the result.  This is exactly what users expect.

> > This means that if a source document XIncludes another source document
> > that is available statically on disk/network, as in your use case, then
> > the above will work OK.
> >
> > However, if a source document includes source content that is
> > dynamically generated, for example, pulled from a database/RSS Feed/Jira
> > instance etc. then we would have to fire up Forrest to generate these
> > sources. If we are validating source documents before we fire up Forrest
> > we end up in a catch 22.

No more so than is already the case.  At the beginning of this thread I
was trying to use xi:include to include straight text.  I got this to work
with 'forrest run' by properly declaring xmlns:xi in the document element.
But I couldn't get by 'forrest site' without modifying the DTD.  Anyone
XIncluding dynamic content would already have the same experience: they
could only get through validation by either disabling validation for
documents using XInclude or by defining a new DTD which includes
xi:include elements.  The former means that the end document is just not
validated, which for some users will be a serious problem.  The latter is
a pain in the neck and doesn't comply with XML standards.  It only works,
insofar as it does, because internally Forrest ignores the augmented DTD,
the one declaring xi:include elements.

> > One solution would be to fire up a running instance of Forrest (aka
> > forrest run) and have Xerces validate the xincludes by retrieving them
> > from the running instance of Forrest. But this really is clumsy and I
> > would guess non-trivial.
> >
> > My point is, any solution that is created to better support the first
> > use case (including static content) must also work in the second use
> > case (including dynamic content).
>
> Let me clarify so as not to discourage your hunt for a solution...
>
> Any solution would need to work alongside a solution that works for the
> dynamically generated content stuff. Personally, I think being able to
> turn off validation on certain pages, as is currently the case, is just
> fine.

A cleaner solution, which involves little work, is to add an include
element to document-v20, which has the same attributes as xi:include.
Also permit a xmlns:xi attribute on the document.  Internally Forrest
would replace <include> elements with <xi:include> elements, preserving
the attributes.

Then turn on XInclusion in the parser.

Advise users that if they want to avoid validation of XIncluded XML
(because the XML doesn't exist yet, because it isn't static) they should
use the <include> element - which could only be used in certain places.

If they want validation, they would use the <xi:include> element, which
XML allows to be used much more widely.

In either case anyone wanting to use XInclude would have to add the
xmlns:xi attribute to the document element.
--
Jim Dixon  jdd@dixons.org   tel +44 117 982 0786  mobile +44 797 373 7881

Mime
View raw message