I want to include material from a document whose DTD I don't control into a document whose DTD I control, and be able to point to identifiers in the included material. I agree with Tim's principle of element-centering, and I think Martin's proposal is basically on the right lines, but a bit too inflexible in being focussed on external entities with particular public identifiers.
The proposal which follows has two components: an explicit, prolix syntax based on marked sections, and an element-centred short form.
I propose to add a single new production:
namespaceSection ::= '<!NS[' %Name '[' (%markupdecl*|%content*) ']]>'
Existing productions would need to be changed to allow namespaceSection in expansions of markupdecl and content.
The intent is that for something like
<!NS[ some-identifier [
the syntax is meant to be very similar to e.g. an INCLUDE marked section, but has the additional impact that every Name which appears inside it (i.e. element GIs, attribute names, identifiers, enumerated types) is particular to the namespace identified by 'some-identifier'. The consequence of this inside the namespace section is zero. The consequences of this outside are 2:
<book id=b1>Troilus and Cressida</book>
Here's an extended example, which uses two namespace sections, one to declare element types etc. and one to use them:
I think I agree with Andrew Layman that you should only be able to refer to a Name inside a namespace section from outside with qualified Name, even if the Name is not defined in the referring context, because that's non-monotonic in an unreasonable way, i.e. the referent of an IDREF might change simply because you add some new text to your document.
On the other hand I think it might be sensible to allow reference out of an namespace section to the
:higherId, but it's not clear that would be very
sensible or useful.
The overhead, both conceptual and literal, of using namespace sections within a document instance is acceptable for importing a single large sub-document as in the example above. It becomes less acceptable in the case of DTD fragment use, as exemplified in a number of recent examples from Andrew Layman, Martin Bryan and others.
If we assume that the documents we have in mind to construct using DTD fragments are to be valid(atable), then I claim no additional syntax is required, and all that is necessary is to define instance validity in terms of automatic namespace scoping within explicitly qualified element GIs and attribute names. That is, formally
As I see it the crucial difference is that neither authors nor parsers need to worry about marking namespaces on every element and attribute, and that document modifications are monotonic, that is, you can't break existing documents by simply adding things to their DTD. This is an acceptable price to pay, in my view, for losing local transparency. That is, in isolation you can't tell what the namespace of a node is, you need to be able to check its ancestors.
Note further that this approach has the nice property that Martin's does of allowing multiple (e.g. CALS) fragments to be imported into the same namespace.
If I just want namespaces to allow me to reuse simple IDs, I have to go to a lot of trouble. This is not a bit deal, it's just a matter of elegance. Suppose I want to tokenise all the paragraphs in a document, using the same IDs repeatedly. Namespaces nearly, but not quite, do what I want:
This isn't actually valid, alas, if all I have in the DTD is
<!element p (w*)>
P2:W, which are the GIs
which really occur in the instance, are not allowed in
P. Either I have to include a disjunction over all the qualified forms
W I intend to use, or I have to use
:W everywhere instead of
I think this is marginal enough a need that the second workaround is acceptable, which is to say I haven't thought of a hack to address it which I think I can sell :-)
I recognise that this really breaks SGML. If there's any chance that WG8 will grandfather this, I think it's worth it. To me, going the CONCUR route just for compatibility is not worth it, I'd rather have no official namespace mechanism at all than that one.