#210 Add sections in Volume 2 and 3.

asciidoc/volume2/qnames/tf2-ch-a-mdpws-qnames.adoc

@@ -0,0 +1,23 @@
+==== Processing of QNames
+
+<<term_q_name>>s are problematic when used in XML element or attribute content (see <<vol3_clause_extension_qname>>).
+Unfortunately, the BICEPS Participant and Message Model as well some Web Services standards that are normatively referenced by <<ref_oasis_dpws_2009, DPWS>>, use <<term_q_name>>s in XML element or attribute content.
+
+In order to increase interoperability between implementations of this profile, this section specifies requirements towards <<term_q_name>> handling in XML instances.
+
+.R1012
+[sdpi_requirement#r1012,sdpi_req_level=shall]
+****
+
+A <<vol1_spec_sdpi_p_actor_somds_participant>> shall resolve the namespace of a prefixed <<term_q_name>> in XML attribute values and content of elements to the namespace that is associated with its prefix and is valid for the smallest element, which encloses the <<term_q_name>>, by XML content.
+
+****
+
+.R1013
+[sdpi_requirement#r1013,sdpi_req_level=shall]
+****
+
+A <<vol1_spec_sdpi_p_actor_somds_participant>> shall resolve the namespace of an unprefixed <<term_q_name>> in XML attribute values and content of elements to the default namespace that is valid for the smallest element, which encloses the <<term_q_name>>, by XML content.
+
+****
+

asciidoc/volume2/tf2-ch-a-mdpws.adoc

@@ -79,4 +79,6 @@ include::mdpws-compression/tf2-ch-a-mdpws-compression.adoc[]
 
 include::discovery-scopes/tf2-ch-a-mdpws-discovery-scopes.adoc[]
 
-include::pretty-print/tf2-ch-a-mdpws-pretty-print.adoc[]
+include::pretty-print/tf2-ch-a-mdpws-pretty-print.adoc[]
+
+include::qnames/tf2-ch-a-mdpws-qnames.adoc[]

asciidoc/volume3/biceps-content-module/tf3-ch-8.3.2.9.1-extension-constraints.adoc

@@ -0,0 +1,52 @@
+====== Extension Constraints
+
+[sdpi_level=+1]
+====== Mixed Content
+
+Some XML processor APIs do not support ordered access to XML Schema _mixed content_, which is the interlacing of XML elements with text content.
+
+.Example of mixed content in an XML instance
+[source#vol3_clause_extension_constraints_interlaced,xml]
+----
+<foo>
+    <bar>
+        Here
+        <interlaced1/>
+        is some
+        <interlaced2/>
+        <interlaced3/>
+        interlaced
+        <interlaced4/>
+        text
+    </bar>
+</foo>
+----
+
+There are APIs that do not fully implement the XML Document Object Model and hence cannot individually access text nodes (e.g. as in <<vol3_clause_extension_constraints_interlaced>>: "Here", "is some", "interlaced", and "text") in between the interlaced elements but only as concatenated text.
+This makes verification measures unnecessarily complicated.
+As mixed content is not required to be available in device to device communication, <<r0019>> prohibits the use of mixed content types in BICEPS extensions.
+
+.R0019
+[sdpi_requirement#r0019,sdpi_req_level=shall]
+****
+A <<vol1_spec_sdpi_p_actor_somds_participant>> shall not provide BICEPS extensions that use XML Schema mixed content types.
+****
+
+[#vol3_clause_extension_qname, sdpi_level=+1]
+====== QName
+
+A <<term_q_name>> is a tuple of a namespace plus a local name.
+In its serialized form, a <<term_q_name>> is represented by either a prefix plus the local name or without a prefix, which translates to the default namespace or no namespace if no default is specified.
+As long as <<term_q_name>>s are used as part of element or attribute names within an XML instance, its usage is well-defined.
+
+The use in element or attribute content however is specific to the application and hence not standardized at all.
+Depending on the XML Schema awareness, each XML processor handles <<term_q_name>>s in element or attribute content differently, to the extent that some are not round-trip-safe and others just pass through the element value to the user of the API.
+While the former may lead to interoperability issues, the latter is a leaky abstraction and requires API users to gain access to the XML instance that included the <<term_q_name>>.
+
+In order to strengthen interoperability and avoid leaky abstraction, <<r0020>> prohibits the use of <<term_q_name>> types in BICEPS extensions.
+
+.R0020
+[sdpi_requirement#r0020,sdpi_req_level=shall]
+****
+A <<vol1_spec_sdpi_p_actor_somds_participant>> shall not provide BICEPS extensions that are based on or use the XML Schema QName type.
+****

asciidoc/volume3/tf3-ch-8.3.2-biceps-content.adoc

@@ -210,15 +210,17 @@ Consequently, a manufacturer of a <<vol1_spec_sdpi_p_actor_somds_provider>> shou
 
 There are standardized extensions, like those that are specified in the PKP standards or this specification, which can be considered common knowledge and therefore do not break interoperability between different manufacturers.
 
-include::biceps-content-module/tf3-ch-8.3.2.9.1-applicable-productions-specification-type-codes.adoc[]
+include::biceps-content-module/tf3-ch-8.3.2.9.1-extension-constraints.adoc[]
 
-include::biceps-content-module/tf3-ch-8.3.2.9.2-applicable-attribute-type-codes.adoc[]
+include::biceps-content-module/tf3-ch-8.3.2.9.2-applicable-productions-specification-type-codes.adoc[]
 
-include::biceps-extension-provisions/tf3-ch-8.3.2.9.3-extension-coded-attribute.adoc[]
+include::biceps-content-module/tf3-ch-8.3.2.9.3-applicable-attribute-type-codes.adoc[]
 
-include::biceps-extension-provisions/tf3-ch-8.3.2.9.4-extension-gender.adoc[]
+include::biceps-extension-provisions/tf3-ch-8.3.2.9.4-extension-coded-attribute.adoc[]
 
-include::biceps-extension-provisions/tf3-ch-8.3.2.9.5-extension-equipment-identifier.adoc[]
+include::biceps-extension-provisions/tf3-ch-8.3.2.9.5-extension-gender.adoc[]
+
+include::biceps-extension-provisions/tf3-ch-8.3.2.9.6-extension-equipment-identifier.adoc[]
 
 // 8.3.2.10
 include::mdib-efficieny/tf3-ch-8.3.2.10-mdib-efficiency-considerations.adoc[]