[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: XML Repository v. 2
Fri, 17 Dec 1999 Zvi Avraham wrote:
>> [...snipped...]
>> The current design shows that the XML data is parsed at server side.
>> The addDocument() method just gets the byte stream. The question is:
>> What is to do, if a <!DOCTYPE> Element is parsed that references an
>> external DTD-file? Something like
>> <!DOCTYPE STANDARD.DIN SYSTEM "DIN0907.dtd">
>> The server side does not know how to handle to find this document b/c
>> it resides (mostly?) on client side! Solutions can be:
>> 1. make a connection to the client which is adding the document and
>> download the DTD
>> 2. initialize the Repository with a set of DTDs to use
>> 3. modify the addDocument() method to pass the DTD data to the server
>> and save this for later requests of DTDs
>> 4. parse at client side
>> Any comments on this?
>
>the most logical solution is 4, but it's also most uneffiecient for current Ozone architecture.
I think parsing on client side is not suitable. The most efficient way would be
parsing inside ozone - not just parsing on server side and converting to ozone
objects like the current DOMConverter solution. Maybe somebody can check the
possibility to change the ElementFactory to ozones DocumentImpl instead of
using OpenXMLs implementation? There is a runtime option in
"openxml.properties" for this.
>BTW you will have the same problem with external entities too.
Right.
>In Cocoon this partly solved by associating BaseURL with the document, then at least in HTTP case,
>Cocoon know where to look for DTDs and external entities. This similar to 3.
Getting the external reference (DTD or Entity) with http is not that problem.
But what about the "file:/" protocol?
>Also maybe possible some mix of 2 and 3. When you can specify in addDocument() if DTD
>is resides in Repository or external ...
>> In DOM it is not allowed to add Documents as childern of other Documents.
>> For this we´ve introduced the XLink Element to store the Document as an
>> member of an Element. But XPath is unable to correctly interpret this new
>> Element. (something like XLink.getChildNodes() will return null ...).
>> So it is impossible to query Documents with just one XPath query. We´ve
>> mentioned this in the first "XML Repository" mail - you need two of them.
>> First query all Documents which match the location path and then search
>> the whole bunch of Documents. Is that mechanism easy to understand for
>> users of the XML Repository? Any other solutions?
>
>Maybe it's possible to modify OpenXML DOM for this ?
>I mean to implement XLink as non-stard DOM Node type ?
>Just an idea :)
The problem I see is that you only have functions like getParentNode(),
getNextSibling() etc. to traverse the DOM tree. If we want to be able
to retrieve the different 'real' Documents as we stored them we need
"context-sensitive" implementations of these functions.
First context: XPath must be able to directly jump to the "starting"
element of a persistent Document (the result of getDocumentElement()) -
while getParentNode() have to return the corresponding node in the
Root-Document. That means the double-linked DOM tree must work at
least over two different Documents.
Second case: If you have selected a part of the persistent Document
(using XPath) you must be able to get the original Document node (named
D8000.xml in the sample below). But appendChild () changed the
ownerDocument to NORM.
NORM
|
|--DIN
| |
¦ |--8000 D8000.xml
| | | |
| | | |
| | |------- <NORM>
| | <...></...>
| | </NORM>
| |
| |--9000
|
|--ISO
Seems to be a little tricky to handle.
Lars
--
________________________________________________________________
Lars Martin mailto:lars@softwarebuero.de
softwarebuero m&b (SMB) http://www.softwarebuero.de