Dear Jack,

it's true that the fn:doc() function cannot be used in BaseX to access
documents in a database - except for the special case that the
database is a disk-based representation of a single document. It is
possible, however, to access single documents in a database by
specifying a full path as fn:collection() argument or adding a second
argument to the db:open() function [1]:

- collection("DB/doc.xml")
- db:open("DB", "doc.xml")

While the first query will potentially try to also locate the disk in
the local file system, the second one restricts the access to
documents stored in databases.

As XQuery was never focused on databases, it is sometimes tricky to do
justice to all the specification details, in particular because some
of the features are implementation defined while others are not.
Regarding the details on the document-uri() function (..thanks btw for
your diligent lookup..), it would probably be more consistent to
return an empty sequence.

If you feel that the Wiki article referenced below is somewhat
incomplete, feel free to give us more feedback or (..even better..)
feel invited to extend it by yourself ;)

Thanks for your feedback, hope this helps,
Christian

PS: BaseX 7.1 is close...

[1] http://docs.basex.org/wiki/Databases#Access_Resources
___________________________

> In reading the documentation and mail archives, it seems to me that BaseX
> does not support documents in terms of having a single URI referring to a
> single document node. For example, if I add a document using the db:add
> function:
>
> db:add("DB", document { <a/> }, "doc.xml")
>
> And subsequently attempt to retrieve it using the doc function:
>
>             fn:doc("doc.xml")
>
> I get a FODC0002 error. This is discussed in the mail archives, and so far
> as I can tell this is because BaseX only works with collections. It does not
> really address the concept of a documents (excuse me if I am over
> simplifying the issue here). In other words, I am free to add more document
> nodes under the name "doc.xml" therefore it is technically a collection as
> opposed to a document. Is this correct?
>
> A fairly early mailing list thread from 2010-07 addresses a similar and
> suggests an alternative approach where one might retrieve a document in a
> collection as follows:
>
> for $doc in collection('DB')
>
>     where matches(document-uri($doc), 'doc.xml')
>
> return $doc
>
> But, doesn't this run afoul of the W3C recommendation which states for the
> fn:docucument-uri function that:
>
> "In the case of a document node $D returned by the fn:doc function, or a
> document node at the root of a tree containing a node returned by the
> fn:collection function, it will always be true that either
> fn:document-uri($D) returns the empty sequence, or that the following
> expression is true: fn:doc(fn:document-uri($D)) is $D. It is
> implementation-defined whether this guarantee also holds for document nodes
> obtained by other means, for example a document node passed as the initial
> context node of a query or transformation."
>
> In other words, if document-uri is returning 'doc.xml' for a node in
> collection('DB') then I should be able to get that same document node using
> the doc function.
>
> I ask these questions because we are interested in being able to maintain
> XML artifacts as singular documents, and using the collection hierarchy to
> do things such as storing temporary and archived version of these artifacts.
> The approach we are taking right now assumes that there is only one
> document-node under each 'document'. I want to understand the limitations of
> the collection and document implementation in BaseX so that I don't make any
> wrong assumptions (as I think I already have).
>
> Finally, assuming the interpretations are correct, are there plans to make
> any changes in the implementation to support something more in line with the
> hierarchy of db->collection->document? I have seen in previous threads that
> you were seeking feedback on this, and I am curious to know if you still
> are. Is there a major drawback you see to this model that perhaps I have not
> considered? Any feedback is appreciated.
>
> Thanks,
>
> Jack Gager
> Metadata Technology
_______________________________________________
BaseX-Talk mailing list
[email protected]
https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk

Reply via email to