Lists Home |
Date Index |
Some of the off-list responses I've gotten have made me question what I once
thought was a slam-dunk. I'm curious how much if it is a conceptual problem
and how much is just unpleasant terminology.
Let me give the same answers to the same questions, but with XPath-centric
terminology. I'll compare the volume of the ensuing screams. :-)
>how many "root nodes" an XForms processor would see in, or associated
with,a multinamespace XML document which contains three <xforms:model>
An XForms processor would effectively keep form data in (at least) one
internal document per <xforms:model>. Each document has one root node.
Multi-namespace doesn't have any bearing on this.
>For each of those root nodes which an XForms processor sees (I assume that
you will suggest there are three), can you provide the element type (name)
of the document element node which is the child node of the root node
[same answer] The document element node will always map to the user-chosen
XML for the
form. See below.
>Can you also specify how many root nodes a non-XForms processor would see
in the same document
You'd need to read that specification to see what it says. Example: XSLT
would take the document as a whole, with a single root node.
Let's make this really plain. Here's a portion of a document like what you
described, with three <xforms:model>s.
An XForms Processor will have three separate internal documents to keep
of. Serialized, these would look like:
* All 3 documents have a single root node.
* All 3 documents have a single document element node, as a child of
the root node
* The document element nodes are, respectively, my:a, my:b, and my:c
* The root node is special and has no representation in markup.
* In all 3 documents, the html and xforms namespaced stuff is not
present, and barring an extension function like document(), is inaccessible
to XPath expressions.