O que deve estar em vigor para validar um XMLTYPE em um esquema?

Eu tenho um procedimento que gera um XMLTYPE e quero validá-lo em um esquema. O problema é que parece haver um problema de permissão executando createSchemaBasedXML porque quando executo o procedimento como AUTHID DEFINER ele dá o erro "ORA-31050: Acesso negado", mas quando executo como AUTHID CURRENT_USER ele realmente retorna um erro específico de validação (Vou lidar com isso separadamente). CURRENT_USER não é uma solução aceitável.

Minha suposição é que CURRENT_USER funciona porque o usuário tem a função XMLADMIN. Conceder as permissões incluídas na função não resolve o problema, portanto, deve ser a capacidade das funções ignorar as ACLs.

O problema é que consultar RESOURCE_VIEW para a ACL que protege o recurso mostra que ele é protegido por /sys/acls/all_owner_acl.xml. DBMS_XDB.getPrivilegesmostra que o xsd tem todas as seguintes permissões:

  <read-properties/>
  <read-contents/>
  <write-config/>
  <link/>
  <unlink/>
  <read-acl/>
  <write-acl-ref/>
  <update-acl/>
  <resolve/>
  <link-to/>
  <unlink-from/>
  <dav:lock/>
  <dav:unlock/>
  <dav:write-properties/>
  <dav:write-content/>
  <dav:execute/>
  <dav:take-ownership/>
  <dav:read-current-user-privilege-set/>

O uso DBMS_XDB.getAclDocumentmostra que um principal dav:ownertem todos os privilégios, portanto, isso não deve ser suficiente para permitir que o proprietário do esquema crie XML baseado em esquema. Pensando nisso criei um bloco para rodar DBMS_XDB.createResourcecriando uma nova ACL. Posso criar a ACL com êxito e, a partir do SQLDeveloper, posso ver que ela existe no local em que a criei.

Há uma série de lugares em que posso estar errado neste processo, então o núcleo do que estou procurando é o seguinte:

O que deve estar em vigor para validar um XMLTYPE em um esquema?

=== Atualização 03/04/2013 ===
Posso definir o acl para meu arquivo xsd para /sys/acls/all_all_acl.xmle voltar para /sys/acls/all_owner_acl.xml. Como antes, nenhum deles resolve o problema de permissões. Eu também tentei um createResource usando a definição acl copiada de all_owner_acl.xl e usando o mesmo caminho daqueles arquivos de /sys/acls/. Isso pelo menos define com êxito a ACL. Eu o executei para todos os meus XSDs e consultei RESOURCE_VIEW para confirmar se eles estão configurados para a nova ACL. Depois de tudo isso, createSchemaBasedXML ainda fornece um erro de acesso negado. Minha ACL está correta ou pode haver outro problema?

<acl xmlns="http://xmlns.oracle.com/xdb/acl.xsd" 
   xmlns:dav="DAV:" 
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"   
   xsi:schemaLocation="http://xmlns.oracle.com/xdb/acl.xsd 
      http://xmlns.oracle.com/xdb/acl.xsd" shared="true">
       <ace>
         <grant>true</grant>
         <principal>MY_ORACLE_USER</principal>
         <privilege>
           <all/>
         </privilege>
       </ace>
     </acl>

=== Atualização 09/04/2013 ===
Eu tenho um bloco anônimo que pode validar XML com sucesso com base em um esquema. Isso aponta novamente para um problema de permissão que permite que isso funcione quando as funções estão habilitadas, mas não quando não estão disponíveis.

== Atualização 12/04/2013 ===
Todas as evidências que recebo parecem indicar que há algo errado com minha ACL ou talvez mais provável com a maneira como configuro a ACL. Retirar a função XDBADMIN do usuário faz com que o bloco anônimo falhe com um erro de acesso negado, embora eu tenha concedido todas as permissões que a função fornece de acordo com dba_tab_privs. Meu setACL segue este formulário:

DBMS_XDB.setACL('/sys/schemas/MY_ORACLE_USER/account.xsd', '/sys/acls/acl_acc.xml');

Um caso de teste completo pode ser encontrado no Oracle Communities .