XML Concepts Flashcards

Question

How do you use ROOT with AUTO ?

Answer 1

Using Root keyword in combination with the Auto mode produces the same result as it does with the RAW mode, your XML stream will contain a root (named \< root \> by default). To specify a name for te root, put this name in the parenthesis inside single quotes right after the ROOT keyword in your code. Lets see the output of the following query **SELECT** City,FirstName, LastName **FROM** Location **INNER JOIN** Employee on Location.LocationID=Employee.LocationID **FOR XML AUTO, ROOT** Our XML result appears the same as in the prior result, except that now all of our data is enclosed within the opening and closing tags named \< root \>. Similarly the following query will replace the default root tag of \< root \> with \< Jerrin \> SELECT City,FirstName, LastName FROM Location INNER JOIN Employee on Location.LocationID=Employee.LocationID FOR XML AUTO, ROOT('Jerrin')

Answer 2

XML offers a great deal of flexibility in how you can choose to organize your result output. For example, since eight employees are listed under Seattle, then there is really no need to see Seattle listed multiple times. By sorting on the higher level element, you can put all related child elements under the same parent. This way you dont have to repeatedly list the parent element.

Answer 3

1. Each row in XML AUTO is named after the table (or the table alias). 2. Raw does not nest the result of multi-table queries, whereas Auto does. 3. When you use Auto mode with a JOIN query, SQL Server nests the resulting values in the order in which the tables appear in the SELECT list. 4. Auto mode also enables you to specify whether columns are mapped as elements or attributes within the XML stream: 1. If you specify the ELEMENTS option, then your Auto data will appear as elements. 2. If you leave the ELEMENTS option off, then Auto will default to showing your data as attributes 5. You can use Auto to organize your data into either elements or attributes, but you cannot mix them. Your XML result must contain either all elements or all attributes.

Answer 4

The XML Raw and Auto modes are great for displaying data as all attributes or all elements - but not both at once. **If you want your XML stream to have some of its data shown in attributes and some shown as elements, then you can use the XML Path mode.** Let us see the example of the following query **_Query 1_** * *SELECT** \* * *FROM** location AS loc **INNER JOIN** employee AS emp * *ON** loc.LocationID = emp.LocationID * *FOR XML PATH** Much like Raw and Auto, each top-level element has a tag named “row” and by default there is no element. However, unlike the previous modes we’ve seen, **the Path mode defaults to putting all its data in elements.** 1Now we’ll itemize the fields in our query. Query 2 * *SELECT** City, FirstName, LastName * *FROM** location AS loc **INNER JOIN** employee AS emp * *ON** loc.LocationID = emp.LocationID * *FOR XML PATH** The result appears much the same. We see “row” as the default name of the opening and closing tags. We also see nested within each “row”, elements for each of the three fields we itemized in our query (City, FirstName, LastName). you can modify the query so that the XML result will include an \< Employee \> root tag. You can do this by adding the ROOT ('Employee') to the query like shown below * *SELECT** City, FirstName, LastName * *FROM** location AS loc **INNER JOIN** employee AS emp * *ON** loc.LocationID = emp.LocationID * *FOR XML PATH, ROOT ('Employee')**

Answer 5

If you are using an XML Path stream, then by default all of the values will be shown as elements. **However, you can pick one or more of your elements to instead be shown as an attribute(s). Use the [@Fieldname] syntax to do this.** Consider the following query **_Query 1_** * *SELECT** City AS [@CityName], FirstName, LastName * *FROM** location AS loc **INNER JOIN** employee AS emp * *ON** loc.LocationID = emp.LocationID * *FOR XML PATH('Employee'), ROOT('Employees')** In the query above we use the alias the city field as [@City]. One easy way to think of this code syntax is to remember that @ (a.k.a. , the "at" sign) goes with "Attributes". In the output we can see that City is now an attribute of \< Employee \> instead of a seperate element.

Answer 6

The element’s name does not need to be named after the field from the table. You can set it to anything you want by specifying a field alias. So all we need to do here is alias the fields using the **AS [ElementName] syntax**. consider the following query **_Query 1_** **SELECT** City AS [@CityName], FirstName AS [First], LastName AS [Last] **FROM** location AS loc **INNER JOIN** employee AS emp **ON** loc.LocationID = emp.LocationID **FOR XML PATH('Employee'), ROOT('Employees')** In the query output we can see that Data previously shown as attributes are still attributes, and all the elements are still elements. The only change is that the original element names (FirstName and LastName) have changed (to First and Last, respectively).

Answer 7

The Path mode also nests elements within other elements. The nesting order is based on the order of fields in your SELECT list. You can specify a custom level by adding a **/ (forward slash)** before each element that you want nested immediately below the new level. **The name of the custom level precedes the forward slash.** Consider the following query for example **_Query 1_** **SELECT** City AS [@CityName],FirstName AS [Name/First], LastName AS [Name/Last] **FROM** location AS loc **INNER JOIN** employee AS emp **ON** loc.LocationID = emp.LocationID **FOR XML PATH('Employee'), ROOT('Employees')** the query output will show a new child-level element \< Name \> which apprears beneath \< Employee \> and includes our aliased elements , \< First \> and \< Last \>.

Answer 8

1. Raw and Auto modes both can use the ELEMENTS option. If ELEMENTS is not used, then both Raw and Auto will display your XML stream in attributes. 2. Path mode queries can produce customized XML layouts of mixed attributes and elements which can’t be achieved by AUTO or RAW. 3. Path mode queries recognize a syntax called XPath to easily customize the layout. 4. Using @ (“at” symbol) at the beginning of your XPath statement tells SQL to make this data part of an attribute. 5. Leaving off @ (“at” symbol) means you want the data in an element. 6. The XPath command allows syntax (like EmployeeID "@EmpID", FirstName "EmpName/First") to put data in both elements and attributes. 7. In XPath you can delimit the field names with ‘ ’ or []. 8. The FOR XML Path clause supports the addition of a root element by appending a ROOT clause at the end of your statement. 9. If you don’t specify the ROOT keyword then there won’t be a root tag set. 10. If you don’t specify a top-level element name after the Path clause, then each record’s element will have the tag.

Answer 9

A nameless field belongs to no tag in your XML file. This can be useful for manipulating your XML stream for readability. The following query will create a Nameless field in the XML output. * *SELECT** EmpID, FirstName **AS [\*]** * *FROM** Employee * *FOR XML PATH('Employee'), ROOT**

Answer 10

1. If the column name is aliased with the wildcard character [\*], then the content will have no named XML element or attribute. 2. The wildcard character \* should be surrounded by square brackets. 3. The wildcard character makes the field nameless in your XML stream. 4. If you have multiple columns with the wildcard [\*] then they will be concatenated together in the same nameless field.

Answer 11

Operations which parse and consume XML data are known collectively by the term **shredding XML.** If you want to take XML data and create a result set in SQL Server, you must first store the XML in memory. The process of preparing XML in SQL includes storing the XML in memory and processing the XML so that all the data and metadata is ready and available for you to query. _**Using sp\_XML\_PrepareDocument**_ When you send an XML document into memory, SQL Server gives you a number (called a handle) which you need later when referring to that document. In Figure 3.14, we will see the “claim ticket” created: we will send our XML document into memory and in exchange we will get back the handle in the form of an integer. To send our document into memory, we first need to declare an XML variable. In order for this variable to contain our XML document, we will set it equal to our XML Next we will declare the variable @hDoc, which we know will be an integer because it is the variable which will act as our document handle (i.e., our “claim ticket”). We will also use sp\_XML\_PrepareDocument, a system-supplied stored procedure which reads our XML document (@Doc), parses it, and makes it available for SQL’s use (Figure 3.13). When we send our XML to SQL Server’s internal cache, we will receive a number which functions as our “claim ticket”. Run all of the code together, including a SELECT statement to display the document handle (i.e., our “claim ticket” which SQL Server provides in exchange for the XML document) (Figure 3.14). **Be sure to run this code only once, otherwise you will create multiple handles and instances of your XML document.** **Our complete query for preparing the XML in memory would be as follows** **DECLARE @Doc XML= '\< cust CustomerID="2" CustomerType="Consumer" \> \< Order InvoiceID="943" OrderDate="2008-02-07T02:45:03.843" \> \< OrderDetail ProductID="72" Quantity="4" / \> \< / Order \> \< / cust \>'** **DECLARE @hDoc int** **Exec sp\_xml\_prepareDocument @hDoc OUTPUT, @Doc select @hDoc** **_Using the OPENXML Function_** We just sent our prepared XML into the SQL Server’s internal cache so that we may pull out the data we want. The OPENXML function provides a rowset view of your XML data. It works with the in-memory copy of the XML document you’ve stored and provides a view of the data, no longer formatted as XML but with all its parts separated into a large grid. This allows you to query just the data that you need. **_Rowpattern_** We know the key to accessing the stored XML document is the document handle or “claim ticket”. The first argument needed by the OPENXML function is this value expressed as an integer. The second argument is the rowpattern hint for the data we wish to see. After declaring an integer variable and setting it equal to 1 (i.e., the value of our document handle, see Figure 3.14), we can use a SELECT statement to query the result set of the OPENXML function. The variable @iNum is the first parameter. The second parameter ‘/cust/Order/OrderDetail’ specifies that we wish to see data for the OrderDetail element level (Figure 3.16). **DECLARE** @iNum INT **SET** @iNum = 1 SELECT \* **FROM OPENXML(@iNum,'/cust/Order/OrderDetail')** Since XML can have root tags, top-level tags, and many levels of child tags, rowpatterns are needed to figure out which level represents your row data. A rowpattern is an XPath pattern telling your query where to look for the data that you want to see in your result. In our current example, the rowpattern hint (‘/cust/Order/OrderDetail’) narrows our query to the attributes found at the OrderDetail element level (Figure 3.16). While the surrounding data isn’t immediately interpretable, we can see the text for the ProductID attribute shows a 72, and the text for the Quantity attribute shows a 4. **_Shredding from the Rowpattern Level_** We want to pull at least one of these columns with the OPENXML function. You might remember that all of our data is at many levels in our XML and the Rowpattern specified the data is at the /cust/Order/OrderDetail level. That level will get our ProductID and Quantity fields as seen in the XML stream below: \< cust CustomerID="2" CustomerType="Consumer" \> \< Order InvoiceID="943" OrderDate="2008-02-07" \> \< OrderDetail **ProductID="72" Quantity="4"** / \> \< / Order \> \< / cust \> Adding the WITH clause to our existing query allows us to pick just the values we wish to see. Our query specifies that we are still interested in data from the OrderDetail element level (Figure 3.17). Our WITH clause lists the field names we want (ProductID, Quantity) from this element level and that these values should be expressed as integer data. In other words, ProductID and Quantity are both integers. **DECLARE** @iNum INT **SET** @iNum = 1 SELECT \* **FROM OPENXML(@iNum,'/cust/Order/OrderDetail')** **WITH (ProductID INT, Quantity INT)** Please note: In the above query you can also alias the column names. for example instead of ProductID you could alias it as ProdID. The example query would be as follows **DECLARE** @iNum INT **SET** @iNum = 1 SELECT \* **FROM OPENXML(@iNum,'/cust/Order/OrderDetail')** **WITH (ProdID INT '@ProductID', Quantity INT)** **In this we have used @ProductID to refer to the element name in the XML.**

Answer 12

1. Before you can process an XML document with T-SQL, you must parse the XML into a tree representation of the various nodes and store it within SQL Server’s internal cache using the sp\_XML\_PrepareDocument stored procedure. 2. The sp\_XML\_PrepareDocument system stored procedure has two required parameters: 1. handle - an integer handle representing the XML document in memory. Think of this as a label on, or pointer to, the XML data in memory. 2. XML - the XML doc to be processed. 3. After you have parsed XML using sp\_XML\_PrepareDocument, SELECT from the OPENXML function result to retrieve a rowset from the parsed tree. 4. The OPENXML function has two required input parameters: 1. iDoc - an integer representing a pointer to the XML document in memory. 2. Rowpattern - an XPath pattern identifying the nodes in the XML to be processed as a rowset 5. The SELECT statement’s WITH clause is used to format the rowset and provide any required mapping information (e.g., mapping a field alias to an attribute). 6. The complete process of transforming XML data into a rowset is called shredding. 7. Each time sp\_XML\_PrepareDocument is executed within the same Query Editor Window session the document handle is returned as an integer that increments by 2 (i.e., 1, 3, 5, 7, 9, etc.).

Answer 13

The OPENXML function offers some helpful options for querying. This section will explore the two main syntaxes for 1. rowpattern recursion (searching lower levels) and 2. column pattern options (searching one level higher).

Answer 14

It’s common to see elements inside of elements with the same name. Sometimes the name of the element is more important than its exact level. In other words, you could see one employee level nested beneath another employee level, and so forth. In our example, we will see how level recursion can help us locate the data we need within XML tags having the same name. Let’s create a simple XML document showing a small organization having one boss, Tom. Tom will have two employees, Dick and Harry. **_XML as shown below_** \< Root \> \< Emp User = "Tom" \> \< Emp User = "Dick" / \> \< Emp User = "Harry" / \> \< / Emp \> \< / Root \> The details about the XML are in the screenshot attached. Let us see the following code to extract data from the above XML. DECLARE @hDoc INT DECLARE @Doc XML SET @Doc = '\< Root\> \< Emp User = "Tom" \> \< Emp User = "Dick" / \> \< Emp User = "Harry" / \> \< / Emp \> \< / Root \>' **EXEC** sp\_XML\_PrepareDocument @hDoc OUTPUT, @Doc * *SELECT** \* * *FROM OPENXML**(@hDoc ,**'/Root/Emp'**) * *WITH** (EmployeeName VARCHAR(max) '@User') The output of the above select would be TOM. Our Rowpattern parameter ('Root/Emp') specifies that we want only the top-level element. If we modify the above select to something like this * *SELECT** \* * *FROM OPENXML**(@hDoc ,**'/Root/Emp/Emp'**) * *WITH** (EmployeeName VARCHAR(max) '@User') In the above code the child-level element ( rowpattern '/Root/Emp/Emp') contains Dick and Harry. A slight modification to our rowpattern parameter specifies that we want to pull data from every level, at or beneath the , and having an XML tag named (code shown below). This is an example of using rowpattern’s relative navigation capability. Thus far our row level specifications have been absolute - our OPENXML queries have explicitly named each level and instructed SQL Server to pull data from that level. In our next section, we will see some of the tools SQL Server makes available for relative navigation of our XML data. * *DECLARE** @iDoc **INT** * *SET** @iDoc=1 * *SELECT** \* * *FROM OPENXML**(@iDoc,**'/Root//Emp'**) * *WITH** (EmployeeName VARCHAR(max) '@User')

Answer 15

The OPENXML function similarly offers us the option of pulling data in a relative fashion. In other words, instead of explicitly naming the element levels where we want SQL Server to navigate and pull data, our code can provide rowpattern (rowpattern) or column pattern (ColPattern) instructions relative to a specified context. In our next example, the rowpattern option will help us pull data from another level relative to our current position. Recall our example of a large organization with many employee levels. You can use the rowpattern’s ability to query relatively and find the managers who are two levels above a certain manager. Perhaps you’ve been asked to compile a list of all the employees who are three levels beneath your manager. The new trick here will be to add ‘…/’ to the front of the column pattern (ColPattern) parameter, e.g. ‘../@User’ (Figure 3.32), which tells SQL Server to search the level above. In other words, we want SQL Server to go up one level from the current context and retrieve the User attribute from that level. The syntax '../../@User' would tell SQL Server to go up two levels and retrieve the User attribute. Since our rowpattern itself ‘/Root//Emp’ is relative, it will search for data at the root level and every child-level below. If the ‘/Root//Emp’ rowpattern finds an employee at the fifth level, then the ‘../@User’ colpattern specifier will go up one level (i.e., up to the fourth level) to search for corresponding data. For example, when the rowpattern instruction ‘/Root//Emp’ locates an Emp level, the colpattern ‘@User’ will find the first User attribute (Dick) at the Emp level. The colpattern ‘../@User’ instructs SQL Server to retrieve the User attribute (Tom) from the level above Dick’s level (Figure 3.33). **DECLARE** @iDoc INT **SET** @iDoc=1 **SELECT** \* **FROM OPENXML**(@iDoc,'**/Root//Emp**') **WITH** (EmployeeName VARCHAR(max) '@User', BossName VARCHAR(max) **'../@User'**)

Answer 16

The sproc sp\_XML\_RemoveDocument will remove an XML document and its handle from memory.

Answer 17

1. If you have several levels of elements with the same name, you can specify all of the levels in your rowpattern by using a double forward slash before the element name: o /Root/Employee - Gets only the top-level Employee elements o /Root//Employee - Gets the Employee elements at all levels 2. If you want to get data one level above the current level then you specify two dots and a forward slash. The XPath syntax to go up 1 level is ‘../’ before the ColPattern (column pattern). 3. You can have multiple XML trees inside the SQL cache at the same time. 4. Once an XML tree is no longer needed, use sp\_XML\_RemoveDocument to remove it from the internal cache. 5. In SQL Server 2005, once your query window is closed and your session is done, the internal cache will be cleared. In such cases, you will not need to use the sp\_XML\_RemoveDocument procedure. 6. Even though you aren’t required to use sp\_XML\_RemoveDocument, it is recommended that you include a remove document step inside stored procedures because the connection to SQL Server is maintained for a longer time where a web service or website makes the connection to SQL Server. 7. Because @hDoc is a local variable, the sp\_XML\_RemoveDocument must be in the same query session as the sp\_XML\_RemoveDocument. 8. In SQL Server 2000, the memory used by the internal cache was not cleared by closing your session. You had to use the sp\_XML\_RemoveDocument procedure or face serious memory leaks.

Answer 18

While a rowpattern only lets you pick one level, a column pattern (sometimes called colpattern) allows you to specify a level for each column in your data. Lets prepare a query first **DECLARE** @hDoc INT **DECLARE** @Doc XML SET @Doc = ' \< cust CustomerID="2" CustomerType="Consumer" \> \< Order InvoiceID="943" OrderDate="2008-02-07" \> \< OrderDetail ProductID="72" Quantity="4" / \> \< / Order \> \< / cust \>' **EXEC** sp\_XML\_PrepareDocument @hDoc OUTPUT, @Doc ``` SELECT \* FROM OPENXML (@hDoc , '/cust/Order/OrderDetail') ``` This query would pull data from just one level as mentioned in the rowpattern '/cust/Order/OrderDetail' **_Going Up One Level_** Suppose we want to see InvoiceID in our result set, but that data is not at our current rowpattern level **(/cust/Order/OrderDetail)**. This data is one level above our rowpattern at the **/cust/Order** level. **We can add a colpattern hint (../) to specify that we want data pulled from a parent level of our current rowpattern. To go up one level, use the XPath syntax ../@AttributeSpecification in the column pattern.** Now we will narrow down our result by specifying the three columns OrderDate, ProductID, and Quantity. In Figure 4.3, we can see the latter two values are already being retrieved by our query (ProductID 72 and Quantity 4) because the rowpattern specifies the OrderDetail level. However to get OrderDate, we need our query to also pull from the Order level, which is one level higher than our other data. The column pattern hints (@OrderDate, @ProductID, @Quantity) specify that we want the values of the attributes (denoted by the @ symbol) pulled from each of these three columns. The additional ../ hint used with @OrderDate (‘../@OrderDate’) instructs SQL Server to retrieve the data from one level higher than the rowpattern So our query would now look something like this * *SELECT** \* * *FROM OPENXML** (@iDoc, **'/cust/Order/OrderDetail'**) * *WITH** (OrderDate DATETIME **'../@OrderDate',** ProductID INT **'@ProductID'**, Quantity INT **'@Quantity'**) **Renaming a field** The WITH clause allows you to customize the field headers in your result. SELECT \* FROM OPENXML (@iDoc, '/cust/Order/OrderDetail') WITH (OrderDate DATETIME '../@OrderDate', **ProdID** INT '@ProductID', **Qty** INT '@Quantity') In the above query ProdID and Qty are renamed fields. **Attributes Versus Elements** When pulling data which is contained in attributes, **prefix the field name with the @ sign and enclose it in single quotation marks** (e.g., ‘@Quantity’ as shown in Figures 4.4 through 4.6). **To pull the values for data which is contained in elements, simply list the field name in your WITH clause and enclose the name in single quotes.** **Going Up Multiple Levels** We know the hint **../** instructs SQL Server to search for data one level above the current rowpattern. To specify multiple levels higher than the rowpattern, add another instance of the parent hint (../) to your rowpattern. **The code ../ in your ColPattern will search one level above the rowpattern. The code ../../ in your ColPattern will search two levels above the rowpattern. The code ../../../ will search three levels above the rowpattern, and so forth.**

Answer 19

1. The OPENXML function takes an integer handle parameter which represents your XML and a rowpattern to specify at what level you want to extract your data. 2. The WITH clause contains column patterns which combine the OPENXML function's rowpattern with the XPath instructions for each field. 3. If you are retrieving attribute data at the same level as the rowpattern specified in the OPENXML function, and the field headers are named the same as the fields, then you can omit the XPath for that field.

Answer 20

We are now familiar with the two required parameters of the OPENXML table-valued function: 1. The **document handle** which identifies the in-memory location of the XML document, and 2. The **rowpattern**. There is one more optional parameter which can make your life easier when your data is stored in a mixture of attributes and elements. **OPENXML FLAG(Optional)** The third parameter of the OPENXML function is the flag. The flag is optional - **if you do not specify a flag, your query will search only for values mapped as attributes**. Key values for this flag are 1, 2, or 3: **1 = searches for attributes (if no flag specified, your query will bring in the values which are mapped as attributes)** **2 = searches for elements** **3 = searches for attributes and elements** Consider the following code **DECLARE** @Doc XMLSET @Doc = '\< SalesInvoice InvoiceID="1000" CustomerID="123" OrderDate="2004-03-07" \> \< Items \> \< Item ProductCode="12" Quantity="2" UnitPrice="12.99" \> \< ProductName \> Bike \< / ProductName \> \< / Item \> \< Item ProductCode="41" Quantity="1" UnitPrice="17.45" \> \< ProductName \>Helmet\< / ProductName \> \< / Item \> \< Item ProductCode="2" Quantity="1" UnitPrice="2.99" \> \< ProductName \> Water Bottle \< / ProductName \> \< / Item \> \< / Items \> \< / SalesInvoice \>' DECLARE @HandleDoc INT EXEC sp\_XML\_PrepareDocument @HandleDoc OUTPUT, @Doc DECLARE @iNum INT SET @iNum = 1 SELECT \* FROM OPENXML (@iNum, 'SalesInvoice/Items/Item') WITH (ProductCode INT, Quantity INT, UnitPrice MONEY, ProductName VARCHAR(50)) No flag parameter included in the code above indicates that we only want to see attribute data. Values are present for all fields except the element (), which shows all null values in our tabular result This is because when you use OPENXML and you’re matching on an exact field name, SQL Server looks for attributes by default. ProductName is the precise field name to search for this element. However, our code isn’t searching for an element - it’s searching for attribute data only (Figure 4.12). DECLARE @iNum INT SET @iNum = 1 SELECT \* FROM **OPENXML (@iNum, 'SalesInvoice/Items/Item', 1)** WITH (ProductCode INT, Quantity INT, UnitPrice MONEY, ProductName VARCHAR(50)) Now we see element data because our flag is set to 2 (Figure 4.13). Notice it found a as a child element of the rowpattern. There are no values for ProductCode, Quantity, or UnitPrice, as those are all attributes (Figure 4.10). DECLARE @iNum INT SET @iNum = 1 SELECT \* FROM OPENXML (@iNum, 'SalesInvoice/Items/Item', 2) WITH (ProductCode INT, Quantity INT, UnitPrice MONEY, ProductName VARCHAR(50)) With our flag set to 3, we finally get all of the data points we want to see. The parameter value of 3 instructs our code to look for both attribute and element data (Figure 4.14). DECLARE @iNum INT SET @iNum = 1 SELECT \* FROM OPENXML (@iNum, 'SalesInvoice/Items/Item', 3) WITH (ProductCode INT, Quantity INT, UnitPrice MONEY, ProductName VARCHAR(50)) This optional flag is very handy for bringing in all of the attribute and element data we want. Notice that we are able to accomplish this without needing to specify any custom column patterns in any of our examples (Figure 4.11- Figure 4.14). Again, this is due to the fact that our code specifies field names which match the field names as they appear in the XML document. For any fields which are aliased (i.e., whose names do not match the field names in the XML document), we would need to specify a column pattern in order for our attribute and/or element values to appear in our tabular result (Figure 4.15).

Answer 21

1. The first parameter of the OPENXML function is the document handle (a.k.a., your “claim ticket”). This parameter is required. 2. The second parameter of the OPENXML function is the rowpattern. This parameter is required. 3. The third parameter of the OPENXML function is the flag. This parameter is optional. 4. The OPENXML flags determine attribute or element centricity: 1. use mapping (attributes) 2. use attribute values 3. element values 4. retrieve both element and attribute values