Hi

I created a new schema using the Tamino Schema Editor, and saved it to my WebDAV-enabled collection.

I then used a WebDAV client to try to put a document which would belong in that collection.

I got a 500 error (attached below) - i guess it tried to autoCreateXmlSchema? After restarting the WebDAV server, i was able to PUT the file. However, it got stored in xdav_nonXML.

What do i need to do to ensure that the file is stored as an instance of the schema?

thanks

Jason


---------------

com.softwareag.xtools.xdav.common.XDatastoreException: com.softwareag.xtools.xdav.common.XException: Could not create schema (docname=, doctype=xs:schema, id=) in collection SmartRepository
Cause: NestedException:Tamino access failure (INOXDE7956, Invalid modification of components of sequence detected during schema update, Line 16, Column 20: old schema: tsd:doctype : Contract2,
xs:element : Contract2,
xs:complexType,
xs:sequence , new schema: tsd:doctype : Contract2,
xs:element : Contract2,
xs:complexType,
xs:sequence)
Cause: Could not create schema (docname=, doctype=xs:schema, id=) in collection SmartRepository
Cause: NestedException:Tamino access failure (INOXDE7956, Invalid modification of components of sequence detected during schema update, Line 16, Column 20: old schema: tsd:doctype : Contract2,
xs:element : Contract2,
xs:complexType,
xs:sequence , new schema: tsd:doctype : Contract2,
xs:element : Contract2,
xs:complexType,
xs:sequence)
at com.softwareag.xtools.xdav.datastore.XDbSession.createContent(Unknown Source)
at com.softwareag.xtools.xdav.common.XContentHandler.create(Unknown Source)
at com.softwareag.xtools.xdav.store.XContentStore.createRevisionContent(Unknown Source)
at org.apache.slide.store.AbstractStore.createRevisionContent(Unknown Source)
at org.apache.slide.store.StandardStore.createRevisionContent(Unknown Source)
at org.apache.slide.content.ContentImpl.create(Unknown Source)
at org.apache.slide.webdav.method.PutMethod.executeRequest(Unknown Source)
at org.apache.slide.webdav.method.AbstractWebdavMethod.run(Unknown Source)
at org.apache.slide.webdav.WebdavServlet.service(Unknown Source)
at com.softwareag.xtools.xdav.servlet.XWebdavServlet.service(Unknown Source)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
at org.apache.slide.webdav.filter.LogFilter.doFilter(Unknown Source)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:213)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:260)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:550)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:509)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:432)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:386)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:534)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:530)
at java.lang.Thread.run(Thread.java:484)

Hi Jason,

I guess TWS was up when you created the new schema. TWS caches the schemas in the webdav enabled collections. If you use Schema Editor to create a new schema, the cache is not updated and TWS tries to autocreate the “new” schema, which is rejected by Tamino. As TWS does not know about the new store, instances are stored in xdav_nonXML.

After a restart of TWS the caches are initialized correctly and everything should work fine.

Regards,
Martin

Hi Martin

Thanks for your reply. As mentioned, it ended up in xdav_nonXML (as seen in X-Plorer).

Can you tell me what algorithm TWS uses to decide whether something is XML or not?

XML documents often end up there when PUT via WebDAV (4.1.4.2, or 4.1.1.1); whereas if they are loaded into the same collection using Tamino Interactive Interface, X-Plorer shows them under the expected doctype.

Why does it make a difference whether you PUT via WebDAV, or load via Tamino Interactive Interface?

cheers,

Jason

Hi Jason,

the basic algorithm is as follows:

if a document is not obviously nonXML, TWS tries to to store as XML. If Tamino somehow complains (not wellformed, not compliant to schema, …) TWS stores as nonXML. An XML document, that you may insert via Interactive Interface, should also go to the same doctype when PUTted via WebDAV.

Which client do you use to PUT your document? Is your schema auto-created?

Best regards,
Martin

Hi Martin

The clients I used most commonly are ones which use Slide client library; XML Spy; Web Folders.

All of these PUT the document in xdav_nonxml, whereas the interactive interface puts it in under the doctype.

I had thought one reason this might happen is if the document has a doctype declaration, since that appears to get stripped off when the interactive interace is used. (At least when viewed in X-Plorer, although actually, a packet sniffer shows that the doctype is retained just hidden).

Yes, schema is auto-created.

thanks

Jason

Hi Jason,

does your xml document refer to a DTD? Be sure that it can be found. If you put it into webdavserver, name it somehow like “http://mypc/taminowebdavserver/mycoll/dtd/mydtd.dtd”.

Regards,
Martin

Hi Martin

So it seems then that if there is a DTD declaration, Tamino attempts to use it.

- Does this mean it goes in xdav_nonXML if the document is invalid or can’t be validated?

- Does this also mean Tamino/TWS ignores the TSD schema which would otherwise be used for that doc type?

If my doctype declaration is something like:

“http://mypc/taminowebdavserver/mycoll/dtd/mydtd.dtd”

then i can’t take my document from server “mypc”, and put it into a different server, without editing the document, unless i can use “localhost”:

“http://localhost/taminowebdavserver/mycoll/dtd/mydtd.dtd”

instead of a specific hostname.

Should that work? i tried something like that, but it didn’t work so far, possibly because authentication is on; but in any event the DTD itself declares entities which would also need to be altered to refererence http (i will try this tomorrow).

More generally, can Tamino use a catalog file

http://www.oasis-open.org/committees/documents.php?wg_abbrev=entity

thanks

Jason

Hi Jason,

>> So it seems then that if there is a DTD declaration, Tamino attempts to use it.

not exactly. Tamino will validate against the schema stored in Tamino. WebDAV (or to be more precise, the underlying Tamino API) tries to load the DTD.

>> - Does this mean it goes in xdav_nonXML if the document is invalid or can’t be validated?

Yes, if allowNonXML is switched on.

>> - Does this also mean Tamino/TWS ignores the TSD schema which would otherwise be used for that doc type?

No.

Using localhost should work. Currently the DTD must be found at the location specified at the moment, the XML document is stored in Tamino. It must be an absolute URL, as the parser does not know about the “webdav context”.

Regards,
Martin

Martin,

Your description of what TWS here does not seem to match my experiences.

I took a valid XML file (valid against its DTD), and changed the doctype declaration to point to a URL which didn’t exist. TWS/Tamino still stored it correctly in the right Tamino doctype, exactly as it did when the doctype declaration pointed to the real DTD location.

Why is this? I did have allowNonXML turned on, so it would have been stored somewhere anyway, but in this case it was stored exactly where it should have been, not in xdav_nonXML.

However, in exploring this, I found a major problem (I’m not currently sure if it’s in TWS or Tamino). The document I was originally using was completely valid (AND with the DTD in a place where TWS/Tamino could find it), however, it was being stored in xdav_nonXML.

The only ‘unusual’ thing about this document was that it had (on the root element, in this case) an xml:space=“default” attribute.

However, it did NOT have an xmlns:xml=“…” attribute declaring the xml namespace, because that is not required (the XML namespaces specification agrees with me on that point, the xml namespace is always implicitly declared).

When I added this xmlns:xml=“…” attribute, and uploaded it via TWS again, it was correctly stored as XML (not in xdav_nonXML).

Is this a known (and maybe fixed?) bug, or should I report it directly to softwareAG?