Hello!
I might have a very stupid question but what would be a right and schema definition for a instance like this:
cs:customer
</cs:customer>
Hello!
I might have a very stupid answer, but here is what I have cooked up. (Someone may have a far better solution than this!)
Before we get too far into this, I would like to give a hint that may prevent some troubles later: having the root node “Customers” (plural) leads me to suspect that there will be multiple “cs:customer” nodes within it.
If this is the case, I would recommend that you reconsider this for Tamino. You will gain more benefit from Tamino if you store multiple “cs:customer” documents [in a Collection called “Customers”] rather than one huge “Customers” document [containing all the “customer” documents].
(One huge document is more suited for a filesystem. Tamino will be much faster with multiple documents.)
To get on with answering your question: firstly you should probably change the XML instance so that the “cs” namespace is defined:
<Customers xmlns:cs="http://namespaces.flibble.com/names/cs">
<cs:customer>
</cs:customer>
</Customers></pre><BR>(Use whichever URI is appropriate for the namespace.)<BR><BR>Second, define the "customer" schema (with the "cs" namespace) in Tamino:<BR><pre class="ip-ubbcode-code-pre"><?xml version = "1.0" encoding = "UTF-8"?>
<xs:schema targetNamespace="http://namespaces.flibble.com/names/cs"
xmlns:cs="http://namespaces.flibble.com/names/cs"
xmlns:tsd="http://namespaces.softwareag.com/tamino/TaminoSchemaDefinition"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:annotation>
<xs:appinfo>
<tsd:schemaInfo name="customer">
<tsd:collection name="temp"></tsd:collection>
<tsd:doctype name="cs:customer">
<tsd:logical>
<tsd:content>closed</tsd:content>
</tsd:logical>
</tsd:doctype>
<tsd:adminInfo>
<tsd:created>2003-02-07T15:19:06.899-08:00</tsd:created>
<tsd:modified>2003-02-07T15:22:46.815-08:00</tsd:modified>
<tsd:version>TSD4</tsd:version>
<tsd:server>4.1.1.1</tsd:server>
</tsd:adminInfo>
</tsd:schemaInfo>
</xs:appinfo>
</xs:annotation>
<xs:element name="customer" type="xs:string"></xs:element>
</xs:schema></pre><BR><BR>Then define the "Customers" schema (with no namespace) in Tamino:<BR><pre class="ip-ubbcode-code-pre"><?xml version = "1.0" encoding = "UTF-8"?>
<xs:schema xmlns:cs="http://namespaces.flibble.com/names/cs"
xmlns:tsd="http://namespaces.softwareag.com/tamino/TaminoSchemaDefinition"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:annotation>
<xs:appinfo>
<tsd:schemaInfo name = "Customers">
<tsd:collection name="temp"></tsd:collection>
<tsd:doctype name = "Customers">
<tsd:logical>
<tsd:content>closed</tsd:content>
</tsd:logical>
</tsd:doctype>
<tsd:adminInfo>
<tsd:created>2003-02-07T15:24:29.262-08:00</tsd:created>
<tsd:modified>2003-02-07T15:24:29.262-08:00</tsd:modified>
<tsd:version>TSD4</tsd:version>
<tsd:server>4.1.1.1</tsd:server>
</tsd:adminInfo>
</tsd:schemaInfo>
</xs:appinfo>
</xs:annotation>
<xs:import namespace="http://namespaces.flibble.com/names/cs"
schemaLocation="customer"></xs:import>
<xs:annotation>
<xs:documentation></xs:documentation>
</xs:annotation>
<xs:element name="Customers">
<xs:complexType>
<xs:sequence>
<xs:element ref="cs:customer" maxOccurs="unbounded"></xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
(The “Customers” schema imports the “customer” schema and its targetNamespace “cs”.)
I hope that is helpful,
Trevor.
Thanks Trevor for your reply but…
The problem is that I am using the older version of Tamino 3.1.2.1 (sorry, not mentioned about that earlier) so I can not import any other schemas. I think that would solve the problem so I guess that I must get that newer version on Tamino.
Actually my problem is much wider that I let you understand at the earlier message. We would like to use documents based on ODRL. The problem is that the ODRL-language uses multiple schemas and I can not import those shemas at all. I was wondering if there was a some kind of a trick for creating a schema so I wouldn’t have to import those schemas an still be able to build documents based on ODRL. I guess that’s impossible.
Okay, I have been abled to bring some documents based on ODRL-language but the main problem is indexing. If there is no schema there can not be any indexing - right? Here is one of the documents that I can put to the Tamino but I can not index that because of those multiple namespace prefixes:
I was wondering if there was a way to build for example this document “surrounded” by normal element names and give that element a attribute that could be used for indefin for example
o-ex:rights
</o-ex:rights>
Sorry about this mess. I have been able to send to messages for here that have not been completed yet… Here is the whole message. Please ignore the previous one
Thanks Trevor for your reply but…
The problem is that I am using the older version of Tamino 3.1.2.1 (sorry, not mentioned about that earlier) so I can not import any other schemas. I think that would solve the problem so I guess that I must get that newer version on Tamino.
Actually my problem is much wider that I let you understand at the earlier message. We would like to use documents based on ODRL. The problem is that the ODRL-language uses multiple schemas and I can not import those shemas at all. I was wondering if there was a some kind of a trick for creating a schema so I wouldn’t have to import those schemas an still be able to build documents based on ODRL. I guess that’s impossible.
Okay, I have been abled to bring some documents based on ODRL-language but the main problem is indexing. If there is no schema there can not be any indexing - right? Here is one of the documents that I can put to the Tamino but I can not index that because of those multiple namespace prefixes:
<?xml version="1.0" encoding="UTF-8"?>
<o-ex:rights xmlns:o-ex=“Page not found!” xmlns:o-dd=“Page not found!” reference=“12345”>
o-ex:agreement
o-ex:context
o-dd:dLocation
o-ex:context
<o-dd:uid o-dd:idscheme=“URI”>someuri</o-dd:uid>
</o-ex:context>
</o-dd:dLocation>
o-dd:date
o-dd:fixed2002-03-20</o-dd:fixed>
</o-dd:date>
</o-ex:context>
o-ex:asset
o-ex:context
<o-dd:uid o-dd:idscheme=“URI”>URL:http://foo.pdf</o-dd:uid>
</o-ex:context>
</o-ex:asset>
o-ex:permission
o-dd:display</o-dd:display>
o-dd:print</o-dd:print>
o-dd:modify
o-ex:constraint
o-ex:context
o-dd:remarkJYK:lla on pysyv
Hello Pelle,
I recommend that you upgrade to Tamino 4.1 if it is possible. Tamino 4 has far better support for XML Schema (including support for multiple namespaces) which will make it easier for you to define the ODRL family of schemas.
However, the ODRL family of schemas use a number of features from XML Schema that are not supported by Tamino yet - even with Tamino 4.1.
I had a look at the xmldsig, xmlenc, ODRL-EX and ODRL-DD schemas, and found the following unsupported features:
- Version property
- blockDefault property
- finalDefault property
- attributeGroup
- Type derivation with xsd:restriction and xsd:extension
- xsd:union
- xsd:complexContent
One strategy that you could investigate with either Tamino 3.1 or 4.1 is to define a “skeletal” schema into Tamino. Define the schema with only the root node declared, making it an “open content” schema.
(Then any documents with the matching root node will be stored into this schema, regardless of the rest of their content.)
Then determine where you need to create indices, and define only the parts of the schema necessary to be able to define an index.
How you wish to proceed will probably be largely determined by which Tamino version you decide to use.
At this point I would like to open this thread up to the real Tamino Schema Gurus!
I hope that helps,
Trevor.
… here is an open content schema with which I was able to store your example document into Tamino 3.1.2.1.
Greetings,
Trevor.
rights.TSD3 (984 Bytes)
Hello Trevor!
Thank You very much for your suggestion, it actually worked!!! I can save now documents based on ODRL to Tamino and also index those document by making my own attribute. The attribute can be deleted after words with DOM so the document will maintain it’s validity.
You have no idea how much this ment to me. No more sleepless nights for me (until the next problem occurs).
Take care and thaks again!
Pelle
Hello Pelle,
I’m glad we were able to help you out!
Have fun,
Trevor.
This is a question for trevor, regarding his reply few posts higher.
I am confused when you say the following:
QUOTE: You will gain more benefit from Tamino if you store multiple “cs:customer” documents [in a Collection called “Customers”] rather than one huge “Customers” document [containing all the “customer” documents].
-----------
I don’t get it. How can you store multiple “cs:customer” documents [in a Collection called “Customers”], when if you define a doctype "<tsd:doctype name=“cs:customer”>, one would think that any cs:customer instance you create will be stored within one “big” doctype, no? (cs:customer)
Or, every cs:customer instance is stored where? From the x-plorer it does seem that the doctype is a container for every cs:customer. SO I’d think you;re creating one big document.
Can you pelase clarify this?
Thank you,
Peter
Hello Peter,
sorry for the lack of clarity in my description.
Perhaps it is easier to describe it thusly: I also think of the Doctype as a container for every cs:customer. That would mean - to me - that the unit of storage in the Doctype is a Document - a cs:customer document.
So, to me, a document is to a doctype what a row is to a table in RDBMS terminology.
Perhaps someone with a deeper knowledge of Tamino’s internal storage architecture would be so kind as to correct me!
Greetings,
Trevor.
Hello Trevor.
Thank you for clarifying. I think we are on the same page here.
To recap:
It seems to me that if you separate “assets” (ex: Invoices, Invoice Items, Customers, etc) into individual DOCTYPES then you are following that methodology of using smaller documents, right? It seems to me that’s the only way. Just as in RDBMS you would separate these assets into tables. So I guess the same idea prevails.
Is this what you were trying to get at with your original post?
Thank you
P.S I only ask because I am just in the middle of designing (first on paper) our XML DB. I am starting with the assets (like the Tamino manual suggests), and then I’ll work on the relationships between the assets. I am new at designing XML Databases, so naturally I want to do it as good as possible the first time! 
Peter
Hello Peter,
I think you’re right, we are now on the same page.
My apologies for not being more clear in the first place! (I always try to steer away from terms like “table” and “row”, but these would certainly have simplified the explanation.)
Good luck with your design!
Trevor.