Mark's been talking about Generative Naming lately, and I've also been thinking about the relationship between XML and URIs for quite a while. In the example that Mark is looking at, the content is a straight name. But much of what we do with XML, for better or for worse, is with QNames. I thought it would be interesting to think about what are all the possibilities for mapping a QName to a URI. I chatted with a few folks about this, and came up with a moderately long list.
Once you've got the algorithm determined, it seems straightforward to specify in WSDL how the Qnames are mapped into URIs. WSDL 2.0 has a mechanism for specifying URI encoding which seems eminently usable.
The TAG took on the issue of qname/uri mapping in http://www.w3.org/2001/tag/issues.html#rdfmsQnameUriMapping-6. However, it looked at the entire space of qnames to URIs, including QNames in content. This examines only element Qnames.
There are a few different design points in constructing URIs from QNames.
1. Which URI component to put the Qname in. The Path and Query sections, delimited by "/" and "&" respectively, are the two choices. Additionally, the Path segment can contain path parameters ";".
2. Are Qnames transmitted in lexical form. XML Namespaces and xml do not define a canonical lexical form for Qnames. The XQuery data model roughly uses the form (ns)name for the lexical representation. Other forms include (ns:name), {ns:name}, {ns}name, ns/name, ns.name, name/ns, name.ns. The {} and [] are reserved characters in URIs.
3. If Qnames are transmitted in non-lexical form, whether to use Xpointer style syntax or alternative for declaring namespaces and qnames.
4. If QNames are transmitted in non-lexical form, whether the namespace name needs to be bound to the URI
This example will use a resource identified by http://foo.org/resource/5 that has a representation of <foons:prop xmlns:foons="http://foo.org/ns"/>, and thus has a foons:prop Qname.
The list of possibilities for identifying the Qname:
1. Path separator and parenthesis lexical representation - http://foo.org/resource/5/(http://foo.org/ns)prop
2. Path and hierarchical lexical representation - http://foo.org/resource/5/http://foo.org/ns/prop
3. Path and hierarchical non-lexical representation without ns decl- http://foo.org/resource/5/foons:prop
4. Path parameter and parenthesis lexical - http://foo.org/resource/5;(http://foo.org/ns)prop
5. Path parameter and hierarchical lexical - http://foo.org/resource/5;http://foo.org/ns/prop
6. Path parameter and non-lexical with Xpointer - http://foo.org/resource/5;xmlns(foons=http://foo.org/ns)xpointer(//foons:prop)
7. Path and lexical Variant 2 - http://foo.org/resource/5/prop/http://foo.org/ns - Given that the prop is name characters, one could "know" that the ns trails the name.
8. Path parameter and non-lexical variant 1 - http://foo.org/resource/5;xmlns:foons=http://foo.org/ns;foons:prop
9. Path and Query for ns decl and Non-lexical - http://foo.org/resource/5/foons:prop?xmlns:foons=http://foo.org/ns - To re-use the ns decl, it can't go in the path
10. Query and parenthesis lexical - http://foo.org/resource/5?(http://foo.org/ns)prop
11. Query and period lexical - http://foo.org/resource/5?prop.http://foo.org/ns
12. Query and lexical variant 2 - http://foo.org/resource/5?http://foo.org/ns&prop - Use the convention that ns decls and names are pair-wise in query. Seems that order is preserved. This has the nice feature that no brackets are required.
13. Query and non-lexical Xpointer - http://foo.org/resource/5?xmlns(foons=http://foo.org/ns)xpointer(//foons:prop)
14. Query and non-lexical variant 2 - http://foo.org/resource/5?xmlns(foons=http://foo.org/ns)&foons:prop
15. Query and non-lexical variant 3 - http://foo.org/resource/5?xmlns:foons=http://foo.org/ns&foons:prop
16. Query and non-lexical variant 4 with no ns decl - http://foo.org/resource/5?foons:prop
17. Query and direct encoding http://foo.org/resource/5?<foons:prop xmlns:foons="http://foo.org/ns"/> where the xml is encoded/escaped. I think OASIS SAML is using a gzip encoding of XML.
18. Fragment ID and Xpointer - http://foo.org/resource/5#xmlns(foons=http://example.org/bar)xpointer(//foons:prop) - It is not legal per the HTTP specification to send the fragment identifier "#" portion of the URI in an HTTP request, as that is a client-side only identifier fragment.
I'm interested in your feedback on whether this is a complete list of options for the "simple" case of binding a QName to a URI.
Leave a comment