I am trying to define a new collection in my Tamino Database. This is how I want the database layout to look like, a top level USERS node with many USER nodes, how do I define this in the new schema editor? The new interface is very confusing, any help would be appreciated.
<?xml version="1.0"?>
Knute
User_Schema.xml (522 Bytes)
The new schema editor edits the new Tamino Schemas which are XML Schemas (or a subset of this to be more specific). The interface lends itself to the structure of XML Schemas so I guess if this is confusing it maybe because you’ve not had much exposure to XML Schemas. There’s some very good books out there on this subject.
I would also recommend that you contact your local Software AG as they may have training on XML Schema and/or Tamino v3 itself.
One way I start off is to create a DTD that represents the XML document; import this into the schema editor and start from there.
Mh,
I see you want something along the line of
…
Do you mean, ONE of your XML documents contains ONE users element with many user entries?
Or is it that you want ONE XML document describe one user?
I ask because you talk about database layout. A common misconception is, that Tamino stores all XML instances in one big XML document .
Bottomline: If each of your documents describes one user, the root element of your schema is named user not users.
When you’ve stored thousands of user documents in Tamino and query for it, Tamino returns an result set envelope like this:
ino:responsexql:result
…
</xql:result></ino:response>
Hope that helps sort things out!
Best regards, Andreas
Yes indeed, I want a collection of user elements. I thought you had to have a top level element that was the same name as your collection in order to be able to reference other collections…
Okay, look,
the Tamino-collection notion and your “collection of documents” may be slightly at odds.
Tamino collections are merely organizational units inside a Tamino database. Think of them as folders in the database or partitions. I use them to distinguish different applications’ data inside one database, e.g.
DB-Name: ino31
Collection1: bbs
Collection2: portal
Then, all doctypes specific to the application bbs go inside collection bbs, e.g.
Doctype: posting
Doctype: user
Doctype: stylesheet
Then, these Tamino Doctypes hold the “collection of documents” you’re (most likely) talking about, all the posting XML documents, all the user XML documents and so on.
Referencing this and across the fence to another Tamino-collection is always possible, since all access methods support this addressing scheme:
http://servername/tamino/ino31/bbs?_command
If you’re using the Java API, notice how the Accessor classes need these two information items for initialization: URL to the database (http://servername/tamino/ino31) and the collection (bbs). Then all commands like queries are executed against the given collection. That’s why X-Queries usually start with the Tamino-doctype name, that being the root-element of your schema, e.g. user .
So, in our example, if bbs and portal are to have both a user doctype, there’s no problem of correctly identifying the one or the other, since you always have to give database name AND Tamino-collection.
Let me wrap it up by saying:
When you design your doctype (DTD or schema), you don’t need to care about anything in regard to Tamino. Yes, you should be able to use about any existing DTD / schema, load it into the Schema Editor and have it placed in a Tamino collection of your choice.
Documents adhering to this schema are loaded into the thus prepared storage structure, when - and only when - you send them to the right Tamino-collection. In Interactive Interface you’d set the database name and right next to it the collection name of bbs, go to the “process” entry field and give the path to a user instance (adhering to the User-DTD defined in collection bbs). Tamino goes forth and loads the instance right there.
Then you set the collection entry to portal, set “process” to another file containing a User document adhering to the schema you defined in the portal Tamino-collection and Tamino goes forth and loads it just there.
So you could have two totally different User-dtd/schemas fenced off each other by the different Tamino collections.
When query-ing the one or the other you need to specify the collection, so nothing gets messed up during any operation.
Helps?
Best regards, Andreas
Thanks to everyone who contributed to this thread, I appreciate your help.
I have a collection called dev, which contains a doctype called users with many user documents. I create a GUID to uniquely identify each node.
Knute
-
-
Hestness
Michael
K
City of Tacoma
-
747
Market
ST
None
Tacoma
WA
98402
253-591-5376
253-591-5500
mhestnes@ci.tacoma.wa.us
Sorry, I think you’re off by an inch. Now what you’ve done is putting one big XML document (with root element users) in the database. In SQL terms this is akin to have a table with exactly one row. And that’s most likely not your intention, because now every query will return this whole users-document when you only wanted a select few of user-documents.
The way to go:
Undefine the users doctype.
Define a doctype user, best by editing the XML schema file and dropping the users element there.
Assuming you have a file from which to load the users, edit this file accordingly, that is: remove the wrapping -element.
Then have this file processed by Tamino.
As an result there should be the doctype user in collection dev. And there should be your user documents in there, so that a query for http://servername/tamino/dbname/dev?_xql=user brings up an Tamino response like this:
ino:response…
xql:result
<user ino:id=“1” UID=“18cd1b76-2677-4bb5-93ba-4f093fafb8b9” isInternal=“true” username=“mhestnes” pwd=““>
Hestness
…
<user ino:id=“2” UID=“18cd1b76-2677-4bb5-93ba-4f093fafb8b8” isInternal=“true” username=“aschoedl” pwd=””>
Schoedl
…
</xql:result>…
</ino:response>
The big difference here is that now, every user is an XML document (or in SQL: every user is one row in the table), so that querying can now come up with meaningful results.
Three more things:
1. Every single document has its distinct ino:id assoiated. So when your user-elements have this ino:id attribute, everythings fine.
2. You do not need (and you must not) add the ino:id attribute to your user-schema. The attribute is automatically inserted by Tamino.
3. Though ino:id is distinct over the doctype, your design with an UID for each user is perfectly okay. ino:id is an internal identifier and you should not rely on it to never change. So, please keep the UID.
Best regards, Andreas