| 5. XML applications | ||
|---|---|---|
 | Chapter 1. The raw ideas |  |
| 5. XML applications | ||
|---|---|---|
| | Chapter 1. The raw ideas | |
[S] Having a "standard" transform for HTTP URLs (which are to a significant degree the most common, in terms of scheme, for XML namespaces) would be useful, to the point that I'd be close to suggesting it as a requirement: there must be a standard, straightforward transform for existing XML namespace identifiers to the pragmatic namespace style.
[S] I suggest using non-reversed domain names.
So For instance, I think your example would be better written as:
<head>
<title>Document title</title>
<project.example.com>
<id.example.com>123521123</id.example.com>
</project.example.com>
</head>
I think this has a number of benefits:
- You don't have to explain to non-programmers how to reverse a domain name!
- Although a minor concern, all other things being equal it should be more efficient to parse as the entropy is at the start of the string making it easier to look up.
- IDE code completion tools should work a lot better making editing documents much easier.
- But most importantly, IMO the eye gravitates to the '<' character when looking for an element name. Separating the local name from the '<' character, potentially by some distance, makes the document harder to read. And in the majority of cases the first part of the name is likely to non-conflicting, and a lot of the time you would never have to look at the domain part.
[S] [Refers to Standard Vocabularies]
Another way to achieve this goal is to allow the designer of an XML vocabulary (=a set of namespaces) to define
(a) a list of predeclared namespace prefixes for that vocabulary
(b) a list of local names that are known to be in each of those namespaces
When invoking an XML parser, the user should be able to reference this "vocabulary definition", and the XML parser should use it to resolve (a) any undeclared namespace prefixes, and (b) any unprefixed local names. An "nnML parser" is then an XML parser with built-in knowledge of the nnML vocabulary definition.
For applications consuming the output of the XML parser, there would be no change from the current infoset.
This is orthogonal to changes allowing the use of expanded QNames rather than prefix-based QNames in element and attribute markup.
The third part of the requirement is dealing with "namespace prefixes in content"
[S] I would certainly expect the vocabulary definition to be (usually) produced by the vocabulary designer, not by the document author! I would also expect that one would be able to derive it from a schema or DTD - but in principle, it shouldn't require a schema or DTD.
[S] I [RJ] implemented this kind of thing for one series of Topologi's editors, see NII (PDF) in particular to have simple annotatable declarations of elements in a vocabulary in a flat format. It has a myriad of uses.
[S] You only need to list those elements that can occur embedded in another vocabulary, plus the top-level element. For example, a list item might not make sense without a containing list. So, a docbook list would automatically introduce the docbook namespace for all the elements it contained (until you got down to ones that implied some other namespace, such as "svg" perhaps).
You'd have a reference, which could be cached.
[S] Something along the lines of [Oasis] catalog resolver perhaps?
[S] have a list of elements from a particular vocabulary that the vocabulary's designer baptizes as making sense to embed within another vocabulary. (Specifically, such an element E in vocabulary N could be called a boundary element, and a document D would be boundary-valid iff for every element E', if the parent of E' is in a different vocabulary, then E' is a boundary element.) This provides a sort of light weight validation for compound documents. It also might be semantically interesting to see how elements fall into the two different coarse categories.
Of course, this assumes that elements have consistent local semantics wherever they're found in a vocabulary, but this is not necessarily the case. For example, you could have a 'warning' element that has different weight in different contexts. Perhaps such context-sensitive elements are always non-boundary elements, though.
[S] the user should be able to reference this 'vocabulary definition'". Like - in the DocBook DTD, which, in the future, might contain the <!NAMESPACE org.docbook (para etc)> definitions.
[S] C1: all existing well-formed XML documents continue to be well-formed under the "new" rules;
C2: all "new" well-formed XML documents are also well-formed under the existing ("old") rules and work in existing software.
[S] I proposed here (and in somewhat modified form for Balisage next week) the idea of a miniature schema, a namespace definition file, that (1) identifies elements that introduce a new default namespace, and (2) can refer to other namespace definition files.
I would use a single attribute to refer to a namespace definition file on my top-level element in my instance, or at any other subtree.
"I" here is document author, although an application (such as a Web browser) could have a default namespace dfeinition file.
In this way, I can for example define XHTML such that a math element (say) automatically implies the MathML namespace, an svg element similarly; and I can handle the fact that hred in SVG is in the xlink namespace.
But I can also make my own namespace, and arrange that elements within it are automatically assigned to other namespaces as needed, without extra markup in the document. I suppose the modern way to describe this would be "unobtrusive namespaces" :-)
So that's the sense in which I could combine namespaces.
A disadvantage is that I did not have a good way for explicitly disambiguating by adding prefixes.
[S] What would we lose if attributes were not namespaced?
[S] Just treat members of the xml namespace as special? Since this proposal never cuts up tags around colons, and doesn't assign any meaning to bits before a colon and bits after a colon, xml:id and friends can be just treated as opaque quantities. i.e. <chapter xml:id="foo">Bar</chapter> is OK.
| |  | |
| 4. Element and namespace declaration and syntax |  | Chapter 2. Issues to be resolved |