[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Re: [Sax-devel] XInclude and SAX Incompatibility


sax pic

> OK, I understand your problem better now - although the
> above is not an unparsed
> entity problem. I assume you just wanted to demonstrate
> the point.

Yes, I made a mistake there. A more appropriate example would have been:

foo.xml:
<!DOCTYPE x [
<!ELEMENT x (include)>
<!ELEMENT include EMPTY>
<!ATTLIST include href CDATA #REQUIRED>
]>
<x>
    <include href="bar.xml"/>
</x>


bar.xml:
<!DOCTYPE stuff [
<!NOTATION jpg SYSTEM "jpg">
<!ENTITY foobar SYSTEM "pic.jpg" NDATA jpg>
<!ELEMENT stuff EMPTY>
<!ATTLIST stuff pic ENTITY #IMPLIED>
]>
<stuff pic="foobar"/>

The document after processing would have the same infoset as if foo.xml
was:
<x>
    <stuff pic="foobar">
</x>

The rest of the argument is still relevant, however.

> I know nothing about XInclude, but I would think that it
> is quite problematic
> to merge schema/doctype information from two different
> documents.
> Conflicting declarations? Are the two infosets supposed to
> depend on each other?

The XInclude spec explains what to do in the case of conflicting
declarations.  And the two infosets are supposed to both be able to create
standalone infosets, but some things are allowed to depend on each other
(like IDREFs). But yes, it can be quite problematic :)

> Is it not possible to process both files independently
> (using separate parsers)?
> Why does your process need to retain the unparsed entity
> declaration?
> Once bar.xml is parsed (separately) and the ENTITY
> attribute has been reported
> (within the context of that parse), should the unparsed
> entity declaration
> not be discarded? Or do you say that the rest of foo.xml
> might depend on that declaration?

Well, the point of XInclude is to have the two (or more) documents merged
into a single document -- and in SAX, that means we need to create a stream
of events that combine the separate documents in the appropriate way.  So
we could process both files independently, and then, when both documents
are parsed, figure out what events need to be sent in what order to create
a valid SAX stream.  But this would mean buffering all of the events of all
of the documents, and that's not in the spirit of a stream based API at
all.  So a good XInclude processor for SAX would have to do the merging on
the fly.  As for whether the entity declaration could be discarded -- the
merged document needs to be self contained in its references.  So if it has
a reference to an unparsed entity (or notation), that unparsed entity must
be present in the document, which means an UnparsedEntityDecl event must be
present in the SAX stream.

> I guess I would need to know XInclude to be able to really > understand
your concerns.
> Sorry. :-)

No apology necessary, Karl.  You're making me explain myself better, and
I'm glad someone is taking an interest, too.

Peter


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.