21 Accessing Oracle XML DB Repository Data

This chapter describes how to access data in Oracle XML DB Repository using standard protocols such as FTP and HTTP(S)/WebDAV, and other Oracle XML DB resource Application Program Interfaces (APIs). It also introduces you to using RESOURCE_VIEW and PATH_VIEW as the SQL mechanism for accessing and manipulating repository data. It includes a table for comparing repository operations through the various resource APIs.

This chapter contains these topics:

Overview of Oracle XML DB Repository

Using Oracle XML DB Repository you can store content in the database in hierarchical structures, as opposed to traditional relational database structures.

Figure 21-1 is an example of a hierarchical structure that shows a typical tree of folders and files in Oracle XML DB Repository. The top of the tree shows /, the root folder.

Figure 21-1 A Folder Tree, Showing Hierarchical Structures in the Repository

Description of Figure 21-1 follows
Description of "Figure 21-1 A Folder Tree, Showing Hierarchical Structures in the Repository"

Note:

Folder /sys is used by Oracle XML DB to maintain system-defined XML schemas, access control lists (ACLs), and so on. Do not add or modify any data in folder /sys.

Foldering lets applications access hierarchically indexed content in the database using the FTP, HTTP(S), and WebDAV protocol standards as if the database content were stored in a file system. You can set access control privileges on repository folders and resources.

This chapter provides an overview of how to access data in Oracle XML DB Repository folders using the standard protocols. It discusses APIs that you can use to access the repository object hierarchy using Java, SQL, and PL/SQL.

Two Ways to Access Oracle XML DB Repository Resources

There are two ways to access Oracle XML DB Repository resources:

  • Navigational or path-based access. This uses a hierarchical index of resources. Each resource has one or more unique path names that reflect its location in the hierarchy. You can navigate, using XPath expressions, to any repository resource.

    A repository resource can be created as a reference to an existing XMLType object in the database. You can navigate to any such database object using XPath. See "Navigational or Path Access to Repository Resources".

  • SQL access to the repository. This is done using special views that expose resource properties and path names, and map hierarchical access operators onto the Oracle XML DB schema. See "Query-Based Access to Repository Resources".

See Also:

A Uniform Resource Locator (URL) is used to access an Oracle XML DB resource. A URL includes the host name, protocol information, path name, and resource name of the object.

Repository Terminology and Supplied Resources

Oracle XML DB Repository is the set of database objects, across all XML and database schemas, that are mapped to path names. It is a connected, directed, acyclicFoot 1  graph of resources, with a single root node (/). Each resource in the graph has one or more associated path names: the repository supports multiple links to a given resource. The repository can be thought of as a file system of objects rather than files.

Repository Terminology

The following list describes terms used in Oracle XML DB Repository:

  • resource – Any object or node in the repository hierarchy. Resources are identified by URLs.

  • folder – A resource that can contain other resources. Sometimes called a directory.

  • path name – A hierarchical name representing an absolute path to a resource. It is composed of a slash (/) representing the repository root, followed by zero or more path components separated by slashes. A path component cannot be only . or .., but a period (.) can otherwise be used in a path component. A path component is composed of any characters in the database character set except slash (/), backslash (\), and those characters specified in the Oracle XML DB configuration file, /xdbconfig.xml, by configuration parameter /xdbconfig/sysconfig/invalid-pathname-chars.

  • resource name (or link name) – The name of a resource within its parent folder. This is the rightmost path component of a path name. Resource names must be unique within their immediately containing folder, and they are case-sensitive.

  • resource content – The body, or data, of a resource. This is what you get when you treat the resource as a file and ask for its content. This is always of type XMLType.

  • XDBBinary element – An XML element that contains binary data. It is defined by the Oracle XML DB XML schema. XDBBinary elements are stored in the repository whenever unstructured binary data is uploaded into Oracle XML DB.

  • access control list (ACL) – A set of principals (users or roles) that are allowed access to one or more specific resources.

Many terms used by Oracle XML DB have common synonyms in other contexts, as shown in Table 21-1.

Table 21-1 Synonyms for Oracle XML DB Repository Terms

Synonym Repository Term Usage

collection

folder

WebDAV

directory

folder

operating systems

privilege

privilege

permission

right

privilege

various

WebDAV folder

folder

Web folder

role

group

access control

revision

version

RCS, CVS

file system

repository

operating systems

hierarchy

repository

various

file

resource

operating systems

binding

link

WebDAV


Supplied Files and Folders

The list of supplied Oracle XML DB Repository files and folders is as follows. In addition to using these, you can create your own folders and files wherever you want.

/public
/sys
/sys/acls
/sys/acls/all_all_acl.xml
/sys/acls/all_owner_acl.xml
/sys/acls/bootstrap_acl.xml
/sys/acls/ro_all_acl.xml
/sys/apps
/sys/asm
/sys/log
/sys/schemas
/sys/schemas/PUBLIC
/sys/schemas/PUBLIC/www.w3.org
/sys/schemas/PUBLIC/www.w3.org/2001
/sys/schemas/PUBLIC/www.w3.org/2001/xml.xsd
/sys/schemas/PUBLIC/xmlns.oracle.com
/sys/schemas/PUBLIC/xmlns.oracle.com/xdb
/sys/schemas/PUBLIC/xmlns.oracle.com/xdb/XDBFolderListing.xsd
/sys/schemas/PUBLIC/xmlns.oracle.com/xdb/XDBResource.xsd
/sys/schemas/PUBLIC/xmlns.oracle.com/xdb/XDBSchema.xsd
/sys/schemas/PUBLIC/xmlns.oracle.com/xdb/XDBStandard.xsd
/sys/schemas/PUBLIC/xmlns.oracle.com/xdb/acl.xsd
/sys/schemas/PUBLIC/xmlns.oracle.com/xdb/dav.xsd
/sys/schemas/PUBLIC/xmlns.oracle.com/xdb/log
/sys/schemas/PUBLIC/xmlns.oracle.com/xdb/log/ftplog.xsd
/sys/schemas/PUBLIC/xmlns.oracle.com/xdb/log/httplog.xsd
/sys/schemas/PUBLIC/xmlns.oracle.com/xdb/log/xdblog.xsd
/sys/schemas/PUBLIC/xmlns.oracle.com/xdb/stats.xsd
/sys/schemas/PUBLIC/xmlns.oracle.com/xdb/xdbconfig.xsd
/xdbconfig.xml

Oracle XML DB Repository Resources

Oracle XML DB Repository resources conform to the Oracle XML DB XML schema XDBResource.xsd. The elements in a resource include those needed to persistently store WebDAV-defined properties, such as creation date, modification date, WebDAV locks, owner, ACL, language, and character set.

A resource index has a special element called Contents that contains the contents of the resource.

The XML schema for a resource also defines an any element, with maxoccurs attribute unbounded. An any element can contain any element outside of the Oracle XML DB XML namespace. Arbitrary instance-defined properties can be associated with the resource.

Where Is Repository Data Stored?

Oracle XML DB stores Oracle XML DB Repository data in a set of tables and indexes to which you have access. If you register an XML schema and request that the tables be generated by Oracle XML DB, then the tables are created in your database schema. You are then able to see or modify them. Other users cannot see your tables unless you grant them permission to do so.

Names of Generated Tables

The names of the generated tables are assigned by Oracle XML DB, and can be obtained by finding the xdb:defaultTable attribute in your XML schema document (or in the default XML schema document). When you register an XML schema, you can alternatively provide your own table name, instead of using the default name supplied by Oracle XML DB. If the table specifies binary XML storage, then a document is encoded in binary XML format before storing it in the table.

Defining Structured Storage for Resources

Applications that need to define structured storage for resources can do so in one of these ways:

  • Subclass the Oracle XML DB resource type. Subclassing Oracle XML DB resources requires privileges on the table XDB$RESOURCE.

  • Store data that conforms to a visible, registered XML schema.

Oracle ASM Virtual Folder

The Oracle Automatic Storage Management (Oracle ASM) virtual folder, /sys/asm, is an exception to the description of the previous sections: its contents are Oracle ASM files and folders that are managed automatically by Oracle ASM.

Path-Name Resolution

The data relating a folder to its contents is managed by the Oracle XML DB hierarchical repository index. This provides a fast mechanism for evaluating path names, similar to the directory mechanisms that are used by operating-system file systems.

Resources that are folders have the Container attribute of element Resource set to true.

To resolve a resource name in a folder, the current user must have the following privileges:

  • resolve privilege on the folder

  • read-properties on the resource in that folder

If the user does not have these privileges, then the user receives an access denied error. Folder listings and other queries do not return a row when the read-properties privilege is denied on its resource.

Caution:

Error handling in path-name resolution differentiates between invalid resource names and resources that are not folders, for compatibility with file systems. Because Oracle XML DB resources are accessible from outside Oracle XML DB Repository (using SQL), denying read access on a folder that contains a resource does not prevent read access to that resource.

See Also:

"XDBResource.xsd: XML Schema for Oracle XML DB Resources" for the definition of element Resource and its attribute Container

Link Types

Links in Oracle XML DB can be repository links or document links. Repository links can be hard links or weak links. Document links can also be hard links or weak links, when their targets are repository resources. These terms are explained further in the following sections.

Repository and Document Links

In addition to containing resources, a folder resource can contain links to other resources (files or folders). These repository links, sometimes called folder links, are not to be confused with document links, which correspond to the links provided by the XLink and XInclude standards, and which are also supported by Oracle XML DB. Repository links are navigational, folder–child links among repository resources. Document links are arbitrary links among documents that are not necessarily repository resources.

Repository links represent repository hierarchical relationships. Document links represent arbitrary relationships whose semantics derives from the applications that use them. Because they represent repository hierarchical relationships, repository links can be navigated using file system-related protocols. This is not true of document links. Because document links can represent arbitrary relationships, they can also represent repository relationships. When document links thus target resources, they can also be hard or weak.

See Also:

Chapter 23, "Using XLink and XInclude with Oracle XML DB" for information about document links

Hard Links and Weak Links

Links that target repository resources can be hard links or weak links. Both hard and weak links are references, or pointers, to physical data — (internal) repository resource identifiers. They do not point to symbolic names or paths to other links. Their targets are resolved at the time of link creation. Because they point directly to resource identifiers, hard and weak links cannot dangle: they remain valid even when their targets are renamed or moved. You need the same privileges to create or delete hard and weak links.

The difference between hard and weak links lies in their relationship to target resource deletion. A target resource is dependent on its hard links, in the sense that it cannot be deleted as long as it remains the target of a hard link. Deletion of a hard link also deletes the resource targeted by the link, if the following are both true:

  • The resource is not versioned.

  • The hard link that was deleted was the last (that is, the only) hard link to the resource.

A weak link has no such hold on a resource: you can delete a resource, even if it is the target of a weak link (as long as it is not the target of a hard link). Because of this, weak links can be used as shortcuts to frequently accessed resources, without impacting deletion of those resources.

There is a dependency in the other direction, however: If you delete a resource that is the target of one or more weak links, then those links are automatically deleted, as well. In this sense, too, weak links cannot dangle. Both hard and weak links provide referential integrity: if a link exists, then so does its target.

Another difference between hard and weak links is this: Hard links to ancestor folders are not permitted, because they introduce cycles. There is no such restriction for weak links: a weak link can target any folder, possibly creating a cycle. It is the set of hard links that define the (acyclic) structure of Oracle XML DB Repository. Weak links represent an additional mapping on top of that basic structure.

You can query the repository path view, PATH_VIEW, to determine the type of a repository link: the link information contains the link type. XMLType column LINK of PATH_VIEW contains this information in element LinkType, which is a child of the root element, LINK. Example 21-1 illustrates this. You can also determine the type of a repository link by using the getLink() callback function on an event handler (LinkIn, LinkTo, UnlinkIn, or UnlinkFrom).

Example 21-1 Querying PATH_VIEW to Determine Link Type

SELECT RESID, XMLCast(XMLQuery('/LINK/LinkType' PASSING LINK RETURNING CONTENT)
                      AS VARCHAR2(24)) link_type
  FROM PATH_VIEW WHERE equals_path(RES, '/home/QUINE/purchaseOrder.xml') = 1;

RESID                              LINK_TYPE
--------------------------------   ---------
DF9856CF2FE0829EE030578CCE0639C5   Weak

Creating a Weak Link with No Knowledge of Folder Hierarchy

Suppose that you want to read a file resource that belongs to one of your colleagues. You cannot create a hard link to that resource, to make it accessible for your use, unless you have the privilege <xdb:resolve> on all of the ancestor folders of that file. Having that privilege would mean that you could see all of your colleague's folder names and the structure of the hierarchy down to the target resource.

However, because weak links essentially represent a mapping on top of the real repository structure, which structure is determined by the set of hard links, you can create a weak link to a resource using just its OID rather than its full, named path (URL). Your colleague can determine the OID path to the file, send you that instead of the named path, and you can create a weak link to the document using that OID path. Example 21-2 and Example 21-3 illustrate this.

Example 21-2 prints the OID path for the file resource /home/QUINE/purchaseOrder.xml. User quine can use this to obtain the OID path to the resource, and then send that path to user curry, who can create a weak link to the resource (Example 21-3).

Example 21-2 Obtaining the OID Path of a Resource

DECLARE
  resoid  RAW(16);
  oidpath VARCHAR2(100);
BEGIN
  SELECT RESID INTO :resoid FROM RESOURCE_VIEW
    WHERE equals_path(RES, '/home/QUINE/purchaseOrder.xml') = 1;
    oidpath := DBMS_XDB.createOIDPath(resoid)
  DBMS_OUTPUT.put_line(oidpath);
END;

In Example 21-3, user curry creates a weak link named quinePurchaseOrder.xml in folder /home/CURRY. The target of the link is the OID path that corresponds to the URL /home/QUINE/purchaseOrder.xml. User curry need not be aware of the repository structure that is visible to user quine.

Example 21-3 Creating a Weak Link using an OID Path

CALL DBMS_XDB.Link(/sys/oid/1BDCB46477B59C20E040578CCE0623D3
                   '/home/CURRY', 'quinePurchaseOrder.xml',
                   DBMS_XDB.LINK_TYPE_WEAK);

Restricting Multiple Hard Links

Sometimes, it is useful to restrict the creation of hard links, disallowing multiple hard links to folders or files (or both). In particular, allowing multiple hard links to file resources, but disallowing multiple hard links to folder resources, provides behavior that is similar to that for some file systems, including UNIX and Linux. This can simplify application design, by, in effect, ensuring that each file resource has a unique, canonical hard-link path to it. In addition, preventing multiple hard links to a resource can lead to query performance improvements.

You can configure the prevention of multiple hard links using the following Boolean parameters in configuration file xdbconfig.xml. The default value of each parameter is true, meaning that multiple hard links can be created.

  • folder-hard-links – Prevent the creation of multiple hard links to a folder resource, if false.

  • non-folder-hard-links – Prevent the creation of multiple hard links to a file resource, if false.

Navigational or Path Access to Repository Resources

Oracle XML DB Repository folders support the same protocol standards used by many operating systems. This lets a repository folder act like a native folder (directory) in supported operating-system environments. For example, you can:

  • Use Windows Explorer to open and access Oracle XML DB folders and resources the same way you access other directories or resources in the Windows NT file system, as shown in Figure 21-2.

  • Access Oracle XML DB Repository data using HTTP(S)/WebDAV from an Internet Explorer browser, such as when viewing Web Folders, as shown in Figure 21-3. Figure 21-3 shows a Web browser visiting URL http://xdbdemo:8080/: the server it is connected to is xdbdemo, and its HTTP port number is 8080.

See Also:

"Configuring Protocol Server Parameters" for information about configuring the HTTP port number

Figure 21-2 Oracle XML DB Folders in Windows Explorer

Description of Figure 21-2 follows
Description of "Figure 21-2 Oracle XML DB Folders in Windows Explorer"

Figure 21-3 Accessing Repository Data using HTTP(S)/WebDAV and Navigational Access From IE Browser: Viewing Web Folders

Description of Figure 21-3 follows
Description of "Figure 21-3 Accessing Repository Data using HTTP(S)/WebDAV and Navigational Access From IE Browser: Viewing Web Folders"

Accessing Oracle XML DB Resources using Internet Protocols

Oracle Net Services provides one way of accessing database resources. Oracle XML DB support for Internet protocols provides another way of accessing database resources.

Where You Can Use Oracle XML DB Protocol Access

Oracle Net Services is optimized for record-oriented data. Internet protocols are designed for stream-oriented data, such as binary files or XML text documents. Oracle XML DB protocol access is a valuable alternative to Net Services in the following scenarios:

  • Direct database access from file-oriented applications using the database like a file system

  • Heterogeneous application server environments that require a uniform data access method (such as XML over HTTP, which is supported by most data servers, including MS SQL Server, Exchange, Notes, many XML databases, stock quote services and news feeds)

  • Application server environments that require data in the form of XML text

  • Web applications that use client-side XSL to format datagrams that do not need much application processing

  • Web applications that use Java servlets that run inside the database

  • Web access to XML-oriented stored procedures

Using Protocol Access

Accessing Oracle XML DB using a protocol proceeds as follows:

  1. A connection object is established, and the protocol might read part of the request.

  2. The protocol decides whether the user is already authenticated and wants to reuse an existing session or the connection must be re-authenticated (the latter is more common).

  3. An existing session is pulled from the session pool, or else a new one is created.

  4. If authentication has not been provided, and the request is HTTP get or head, then the session is run as the ANONYMOUS user. If the session has already been authenticated as the ANONYMOUS user, then there is no cost to reuse the existing session. If authentication has been provided, then the database re-authentication routines are used to authenticate the connection.

  5. The request is parsed.

  6. (HTTP only) If the requested path name maps to a servlet, then the servlet is invoked using Java Virtual Machine (VM). The servlet code writes the response to a response stream or asks XMLType instances to do so.

Retrieving Oracle XML DB Resources

When the protocol indicates that a resource is to be retrieved, the path name to the resource is resolved. Resources being fetched are always streamed out as XML, with the exception of resources containing the XDBBinary element, an element defined to be the XML binary data type, which have their contents streamed out in RAW form.

Storing Oracle XML DB Resources

When the protocol indicates that a resource must be stored, Oracle XML DB checks the document file name extension for .xml, .xsl, .xsd, and so on. If the document is XML, then a pre-parse step is done, whereby enough of the resource is read to determine the XML schemaLocation and namespace of the root element in the document. If a registered schema is located at the schemaLocation URL, and it has a definition for the root element of the current document, then the default table specified for that root element is used to store the contents of the resource.

Using Internet Protocols and XMLType: XMLType Direct Stream Write

Oracle XML DB supports Internet protocols at the XMLType level by using Java XMLType method writeToStream(). This method is implemented natively and writes XMLType data directly to the protocol request stream. This avoids Java VM execution costs and the overhead of converting database data through Java data types and creating Java objects, resulting in significantly higher performance. Performance is further enhanced if the Java code deals only with XML element trees that are close to the root, and does not traverse too many of the leaf elements, so that relatively few Java objects are created.

Accessing Oracle ASM Files using Protocols and Resource APIs – For DBAs

Oracle Automatic Storage Management (Oracle ASM) organizes database files into disk groups for simplified management and added benefits such as database mirroring and I/O balancing.

Repository access using protocols and resource APIs (such as DBMS_XDB) extends to Oracle ASM files. These files are accessed in the virtual repository folder /sys/asm. However, this access is reserved for database administrators (DBAs). It is not intended for developers.

A typical use of such access is to copy Oracle ASM files from one database instance to another. For example, a DBA can view folder /sys/asm in a graphical user interface using the WebDAV protocol, and then drag-and-drop a copy of a data-pump dump set from an Oracle ASM disk group to an operating-system file system.

Virtual folder /sys/asm is created by default during Oracle XML DB installation. If the database is not configured to use Oracle ASM, the folder is empty and no operations are permitted on it.

Folder /sys/asm contains folders and subfolders that follow the hierarchy defined by the structure of an Oracle ASM fully qualified filename:

  • It contains a subfolder for each mounted disk group.

  • A disk-group folder contains a subfolder for each database that uses that disk group. In addition, a disk-group folder may contain files and folders corresponding to Oracle ASM aliases created by the administrator.

  • A database folder contains file-type folders.

  • A file-type folder contains Oracle ASM files, which are binary.

This hierarchy is shown in Figure 21-4, which omits directories created for aliases, for simplicity.

Figure 21-4 Oracle ASM Virtual Folder Hierarchy

Description of Figure 21-4 follows
Description of "Figure 21-4 Oracle ASM Virtual Folder Hierarchy"

The following usage restrictions apply to virtual folder /sys/asm. You cannot:

  • query /sys/asm using SQL

  • put regular files under /sys/asm (you can put only Oracle ASM files there)

  • move (rename) an Oracle ASM file to a different Oracle ASM disk group or to a folder outside Oracle ASM

  • create hard links to existing Oracle ASM files or directories

In addition:

  • You must have the privileges of role DBA to view folder /sys/asm.

  • To access /sys/asm using Oracle XML DB protocols, you must log in as a user other than SYS.

Again, Oracle ASM virtual-folder operations are intended only for database administrators, not developers.

See Also:

Query-Based Access to Repository Resources

There are two views that enable SQL access to Oracle XML DB Repository data:

  • PATH_VIEW

  • RESOURCE_VIEW

Table 21-2 summarizes the differences between PATH_VIEW and RESOURCE_VIEW.

Table 21-2 Differences Between PATH_VIEW and RESOURCE_VIEW

PATH_VIEW RESOURCE_VIEW

Contains link properties

No link properties

Has one row for each unique path in repository

Has one row for each resource in repository


Rows in these two repository views are of XMLType. In the RESOURCE_VIEW, the single path associated with a resource is arbitrarily chosen from among the possible paths that refer to the resource. Oracle XML DB provides SQL functions, such as under_path, that let applications search for the resources contained within a particular folder (recursively), obtain the resource depth, and so on.

DML can be used on the repository views to insert, rename, delete, and update resource properties and contents. Programmatic APIs must be used for other operations, such as creating links to existing resources.

Servlet Access to Repository Resources

Oracle XML DB implements Java Servlet API, version 2.2, with the following exceptions:

  • All servlets must be distributable. They must expect to run in different virtual machines.

  • WAR and web.xml files are not supported. Oracle XML DB supports a subset of the XML configurations in this file. An XSL style sheet can be applied to the web.xml to generate servlet definitions. An external tool must be used to create database roles for those defined in the web.xml file.

  • JSP (Java Server Pages) support can be installed as a servlet and configured manually.

  • HTTPSession and related classes are not supported.

  • Only one servlet context (that is, one Web application) is supported.

Operations on Repository Resources

You can operate on data stored in Oracle XML DB Repository resources using any of the following:

  • Oracle XML DB resource APIs for Java

  • A combination of Oracle XML DB resource views API and Oracle XML DB resource API for PL/SQL

  • Internet protocols (HTTP(S)/WebDAV and FTP) and Oracle XML DB protocol server

  • Oracle XML DB Content Connector and, through it, the standard Content Repository API for Java (JCR).

These access methods can be used equivalently. It does not matter how you add content to the repository or retrieve it from there. For example, you can add content to the repository using SQL or PL/SQL and then retrieve it using an Internet protocol, or the other way around.

Table 21-3 lists common Oracle XML DB Repository operations, and describes how these operations can be accomplished using each of several access methods. The table shows functionality common to the different methods, but not all of the methods are equally suited to any particular task. Unless mentioned otherwise, "resource" in this table can be either a file resource or a folder resource.

Table 21-3 also shows the resource privileges that are required for each operation. In addition to the privileges listed in the table, privilege xdb:read-properties is required on each resource affected by an operation. Operations that affect the parent folder of a resource, in addition to the resource targeted by the operation, also require privilege xdb:read-properties on that parent folder. For example, deleting a resource affects both the resource to delete and its parent folder, so you need privilege xdb:read-properties on both the resource and its parent folder.

Table 21-3 Accessing Oracle XML DB Repository: API Options

Data Access SQL and PL/SQL Protocols Resource Privileges Required JCR Support

Create resource

DBMS_XDB.createResource('/public/T1/testcase.txt',
                        'ORIGINAL text');
INSERT INTO RESOURCE_VIEW (ANY_PATH, RES)
SELECT '/public/T1/copy1.txt', RES
  FROM RESOURCE_VIEW
  WHERE equals_path(RES, 
                    '/public/T1/testcase.txt')
        = 1;

HTTP:PUT;

FTP: PUT

DAV::bind on parent folder

Yes

Update resource contents

UPDATE RESOURCE_VIEW
SET RES =
updateXML(
  RES,
  '/Resource/Contents/text/text()',
  'NEW text',
  'xmlns =
"http://xmlns.oracle.com/xdb/XDBResource.xsd')  
WHERE equals_path(RES,
                  '/public/T1/copy1.txt') = 1;

HTTP: PUT;

FTP: PUT

xdb:write-content on resource

Yes

Update resource properties

UPDATE RESOURCE_VIEW
SET RES =
updateXML(
  RES,
  '/Resource/DisplayName/text()', 
  'NewName1.txt',
  'xmlns =
"http://xmlns.oracle.com/xdb/XDBResource.xsd')
WHERE equals_path(RES,
                  '/public/T1/copy1.txt') = 1;

WebDAV:

PROPPATCH;

DAV::write-properties on resource

Yes

Update resource ACL

EXEC DBMS_XDB.setACL(
  '/public/T1/copy1.txt',
  '/sys/acls/all_owner_acl.xml');

not applicable

DAV::write-acl on resource

No

Unlink resource (delete if last link)

EXEC DBMS_XDB.deleteResource()
DELETE FROM RESOURCE_VIEW
  WHERE equals_path(RES, path) > 0

HTTP:

DELETE;

FTP: delete

DAV::unbind on parent folder

xdb:unlink-from on resource

Yes

Forcibly remove all links to resource

DBMS_XDB.deleteResource()
DELETE FROM PATH_VIEW
WHERE
XMLCast(
XMLQuery(
  'declare namespace n1=
"http://xmlns.oracle.com/xdb/XDBResource.xsd"; (: :)
   //n1:DisplayName'
  PASSING RES RETURNING CONTENT)
AS VARCHAR2(256))
= 'My resource'

FTP:

quote

rm_rf

resource

DAV::unbind on all parent folders

xdb:unlink-from on resource

Yes

Move resource

UPDATE PATH_VIEW
  SET path = '/public/T1/copy2.txt'
  WHERE equals_path(RES,
                    '/public/T1/copy1.txt')
        = 1;

WebDAV:

MOVE;

FTP: rename

DAV::unbind on source parent folder

DAV::bind on target parent folder

xdb:unlink-from and xdb:link-to on resource

Yes

Copy resource

INSERT INTO PATH_VIEW (path, RES, link)
  SELECT '/public/T1/copy3.txt', RES, link
    FROM PATH_VIEW
    WHERE equals_path(RES,
                      '/public/T1/copy2.txt')
          = 1;

WebDAV:

COPY;

Copy to new:

DAV::bind on target parent folder

DAV::read on resource

Copy to existing (replacement):

DAV::read on resource

DAV::write-properties and DAV::write-content on existing target resource

Yes

Create hard link to existing resource

EXEC DBMS_XDB.link('/public/T1/copy3.txt', 
                   '/public/T1',
                   'myhardlink');

not applicable

DAV::bind on parent folder

xdb:link-to on resource

No

Create weak link to existing resource

EXEC DBMS_XDB.link('/public/T1/copy3.txt', 
                   '/public/T1',
                   'myweaklink',
                   DBMS_XDB.LINK_TYPE_WEAK);

not applicable

DAV::bind on parent folder

xdb:link-to on resource

No

Change owner of resource

UPDATE RESOURCE_VIEW
  SET RES =
    updateXML(
      RES,
      '/Resource/Owner/text()',
      'U2')
  WHERE equals_path(RES, '/public/T1/copy3.txt')
        = 1;

not applicable

DAV::take-ownership on resource

Yes

Get binary or text representation of resource contents

SELECT XDBURIType(path).getBLOB()
  FROM DUAL;

SELECT
XMLQuery(
'declare default element namespace
"http://xmlns.oracle.com/xdb/XDBResource.xsd";(: :)
 $r/Resource/Contents'
PASSING RES AS "r" RETURNING CONTENT)
FROM RESOURCE_VIEW
WHERE equals_path(RES, '/public/T1/copy2.text') = 1;

HTTP: GET;

FTP: get

xdb:read-contents on resource

Yes

Get XMLType representation of resource contents

SELECT XDBURIType('/public/T1/res.xml').getXML
  FROM DUAL;

SELECT 
XMLQuery(
'declare default element namespace
"http://xmlns.oracle.com/xdb/XDBResource.xsd";(: :)
 $r/Resource/Contents/*'
PASSING RES AS "r" RETURNING CONTENT)
FROM RESOURCE_VIEW 
WHERE equals_path(RES, '/public/T1/res.xml') = 1;

not applicable

xdb:read-contents on resource

No

Get resource properties

SELECT
XMLCast(
XMLQuery(
'declare default element namespace
"http://xmlns.oracle.com/xdb/XDBResource.xsd";(: :)
$r/Resource/LastModifier'
PASSING RES AS "r" RETURNING CONTENT)
AS VARCHAR2(128))
FROM RESOURCE_VIEW
WHERE equals_path(RES, '/public/T1/res.xml') = 1;

WebDAV:

PROPFIND

(depth = 0);

xdb:read-properties on resource

Yes

List resources in folder

SELECT PATH FROM PATH_VIEW
  WHERE under_path(res, '/public/T1') = 1;

WebDAV:

PROPFIND

(depth = 0);

xdb:read-contents on folder

Yes

Create folder

Call DBMS_XDB.createFolder('/public/T2');

WebDAV:

MKCOL;

FTP: mkdir

DAV::bind on parent folder

Yes

Unlink empty folder

DBMS_XDB.deleteResource('/public/T2')

HTTP:

DELETE;

FTP: rmdir

DAV::unbind on parent folder

xdb:unlink-from on resource

Yes

Forcibly delete folder and all links to it

DBMS_XDB.deleteResource(
  '/public/T2',
  DBMS_XDB.DELETE-RECURSIVE_FORCE);

not applicable

DAV::unbind on all parent folders

xdb:unlink-from on folder resource

Yes

Get resource with a row lock

SELECT ... 
  FROM RESOURCE_VIEW
  FOR UPDATE ...;

not applicable

xdb:read-properties and xdb:read-contents on resource

No

Add WebDAV lock on resource

EXEC DBMS_XDB.LockResource('/public/T1/res.xml',
                           TRUE,
                           TRUE);

WebDAV:

LOCK;

FTP:

quote lock

DAV::write-properties on resource

No

Remove WebDAV lock

DECLARE...
BEGIN 
  DBMS_XDB.GetLockToken('/public/T1/res.xml', 
                        locktoken); 
  DBMS_XDB.UnlockResource('/public/T1/res.xml',
                          locktoken);
END; 

WebDAV: UNLOCK;

FTP:

quote unlock

DAV::write-properties and DAV::unlock on resource

No

Check out file resource

EXEC DBMS_XDB_VERSION.checkOut(
  '/public/T1/res.xml');

not applicable

DAV::write-properties on resource

No

Check in file resource

EXEC DBMS_XDB_VERSION.checkIn(
  '/public/T1/res.xml');

not applicable

DAV::write-properties on resource

No

Uncheck out file resource

EXEC DBMS_XDB_VERSION.unCheckOut(
  '/public/T1/res.xml');

not applicable

DAV::write-properties on resource

No

Make file resource versioned

EXEC DBMS_XDB_VERSION.makeVersioned(
  '/public/T1/res.xml');

not applicable

DAV::write-properties on resource

No

Remove an event handler

DBMS_XEVENT.remove

not applicable

xdb:write-config on resource or parent folder (depending on the context)

No

Commit changes

COMMIT;

Automatic commit after each request

not applicable

Yes

Rollback changes

ROLLBACK;

not applicable

not applicable

Yes




Footnote Legend

Footnote 1: The graph is established by the hard links that define the repository structure, and cycles are not permitted using hard links. You can, however, introduce cycles using weak links. See "Hard Links and Weak Links".