Dear Friends,
how to deal with recursive element in new Schema editor(TSD3)?
i.e. how to set the level of recursion in TSD3 thru editor
Thnax
Mangesh

There is no level of recursion anymore.
However if you use indices or collation, they apply for the uppermost level of recursion only.

By “Physical Properties” / “Advanced” Button you open the XPath panel. Here you may specify additional mappings/index settings. If you need an index on another recursion level you enter a XPath that points to this level and choose the index you like. The “XPath” notation is simply to concatenate the element names beginning from the root: “/elementA/elementB/elementC/elementB/elementC” would address the second level of recursion.

Hi,

I wonder if I could get a clarification on that.

Given your example where you’ve got an elementC that can occur several places in the document structure, including

/elementA/elementB/elementC/elementB/elementC

What exactly does applying an index to elementC without adding an Xpath under the Physical Properties / Advanced (i.e. without adding a tsd:which to the tsd:physical node where the index will be applied) do?

I had been assuming that it indexed elementC regardless of where it occurred in the structure. That the default was “anywhere” which I thought should make “//elementC” queries efficient. Is this idea mistaken?

Take another example without recursion: say elementC could occur any of these three places:

/elementA/elementB/elementC/
/elementA/elementD/elementC/
/elementE/elementC

Does it not index elementC in all three locations? Does an index without tsd:which allow "//elementC "queries to find all three cases with the same efficiecy of a more specific query? (like “/elementE/elementC”?)

If so, why should
/elementA/elementB/elementC/elementB/elementC
be any different? With a tsd:which-less index on elementC why should the index builder not simply find all occurances of elementC when it loads the document and index them all regardless of structure?

If an element in a TSD3 schema can be reached on many paths there are 3 potential reasons:

1. explicit recursion via ref’s to global element(s)

2. highly-connected schema with many ref’s to global elements which themselves have again refs to global elements etc.

3. implicit references to global elements due to usage of wildcards (xs:any) with appropriate value of the namespace attribute. This leads to scenarios comparable to 1. and 2.

If no tsd:which is given, the behaviour depends on whether a recursion is being detected:
if a possible path to a given element contains the same element twice, this indicates a recursion and no index will be created.
In your example, this means that there will be
an index for
/elementA/elementB/elementC
but not for
/elementA/elementB/elementC/elementB/elementC.

Otherwise, an index will be created. That means there will be three indexes, one for each path out of
/elementA/elementB/elementC/
/elementA/elementD/elementC/
/elementE/elementC
However, in a highly-connected schema (scenario 2.) Tamino builtin limitations may be reached, because there is a separate index for each possible path.

The reason for the different treatment is: a recursion always leads to an infinite set of possible paths, whereas multiple ref’s without recursion lead to a finite set.

Execution time for a query like “//elementC” is independent of this, as it can be evaluated efficiently, if a full structure index is available. However, standard indexes might be used in a query like “//elementC[.=‘string’]”.