Unlike most of the other Office applications, Access doesn't really have a custom vocabulary, though it adds a few Office-specific pieces to things like the XML Schemas it generates. The vocabulary that Access speaks "natively" is largely determined by the structures of your database, particularly the names of tables and the fields they contain. If you've named your tables and your fields well, you may be pleasantly surprised to find that Access produces some very readable XML. If not, you can't blame Microsoft, but fortunately they provide XSLT facilities for improving your results in such cases.
While Microsoft doesn't provide an Access-specific vocabulary, Access definitely has expectations about the structures of incoming and outgoing XML. The basic structures are very simple, though cases like multi-table export can require more interpretation. The easiest way to learn about the expectations Access has for incoming data is to start with sample information inside the database, and then export it. Close analysis of the exported material should tell you what Access will want for an import.
Generally speaking, XML structures offer a range of structural possibilities that don't map easily to relational database tables. XML doesn't typically worry about things like primary keys and foreign keys, nor are its structures defined as relations between tables. Access does very well at working with a subset of XML structures that is (or can be made to be) relational-database friendly, but there are some natural limitations, as well as fields of work where other pieces of the Office suite are more appropriate tools.