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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

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

[ Lists Home | Date Index | Thread Index ]


> 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





 

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

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