OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: XInclude [was: XLink transformations]

[ Lists Home | Date Index | Thread Index ]
  • From: David Orchard <orchard@pacificspirit.com>
  • To: 'Paul Grosso' <pgrosso@arbortext.com>, xml-dev@xml.org
  • Date: Mon, 24 Jul 2000 21:56:39 -0700

There is no elegent way to remove some particular PIs from an included
document and keep the future of XInclude open.  XInclude must be non-lossy.

XInclude as it stands is simply the first step towards a goal.  Eventually,
I would like to realize some of transclusion in XInclude/XSLT/Query
combinations.  With regard to XSLT, a next logical step for XInclude/XPath
is to add 2 things:
1) the ability to specify what the state of the included document should be,
ie before schema validation, default, after transform, after query, etc.
This might require an xpointer addition to specify state in URIs
2) the ability of the XInclude author to specify when the inclusion itself
should take place, ie before schema validation, defult, after transform,
after query, etc.

Then we could actually meet the use case of an author creating a single
element that specified including a document that has been styled into an
source document after the source document's styling is complete, thus
preserving included documents style aka copyright notice.

Perhaps in XInclude 3.0, sometime 2005.  You laugh, XInclude is now 1
attribute and it's been over a year since it was created and it's not at
last call.

Cheers,
Dave Orchard



-----Original Message-----
From: Paul Grosso [mailto:pgrosso@arbortext.com]
Sent: Thursday, July 20, 2000 8:04 AM
To: xml-dev@xml.org
Subject: XInclude [was: XLink transformations]


At 00:17 2000 07 20 -0700, Ben Trafford wrote:
>Therefore, my initial take on the issue stands, unless XInclude is
>modified to preclude the passing of prolog information. In my opinion, this
>would be a mistake. The prolog contains useful information, including the
>stylesheet PI. It seems to me that it would behoove the XML Core WG to
>consider the merging of information found in the prolog in a compatible
way.

We've considered and rejected it as out of scope.

>In other words, the stylesheet call is valid, according to
>infosets and XInclude. The real question is: how to handle it, since
>multiple stylesheet calls are quite valid in XSL. The only invalid part is
>placing the stylesheet PI outside of the prolog.

XInclude [1] isn't about style semantics, it's more analogous to XML 1.0
external parsed entity handling.

All information in the included bit is included at the including point
(if that sounds tautological, it's supposed to).  This includes PIs.
A stylesheet PI is just a PI to any XML 1.0 processor and/or any
XInclude-compliant processor.  XInclude won't do anything special
with it.  What happens at the application level when a stylesheet PI
is found in the middle of an infoset (instead of in the prolog) is
outside the scope of XInclude.

The "Associating Style Sheets with XML documents" Rec [1] says:

  The xml-stylesheet processing instruction is allowed only in
  the prolog of an XML document.

While it doesn't explicitly say what should happen when a PI that
looks like an xml-stylesheet processing instruction occurs elsewhere
than in the prolog, I would assume an application is free to treat
it as either an error or simply to ignore it.

paul

[1] http://www.w3.org/TR/xinclude
[2] http://www.w3.org/TR/xml-stylesheet/

p.s.  Note that the XML Core WG has just recently (17-July-2000)
published a new WD of XInclude, available for all to comment on.
I meant to post a notice of this to xml-dev, but am only now getting
around to it.  Consider this the notice!





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS