Reserved names and documentation

[james anderson]

I posted a note back in December on the the related topic of "external dtd[s]
and namespaces". (http://www.lists.ic.ac.uk/hypermail/xml-dev/9812/0276.html)

The example shown there refutes the claim that namespaces (in themselves)
places any restrictions on a processor's ability to validate a document. The
only restriction, as noted by Mr Bray below (#1), is that the prefix - URI
binding be known "within the dtd". In the example shown, I used (deprecated)
processing instructions to this effect. In theory, it would be possible to do
this entirely on the basis of declared default attribute values. I haven't
(yet) implemented that.

Tim Bray wrote:
> [in response to the claim, that]
> >Namespace prefixes hate
> >validation.
> 
> Those who've heard my argument on this subject can tune out now.
> Here goes, again.  Namespaces create two problems; an easy syntactic

"namespaces" themselves create no problems. The difficulties arise with the
limited prefix binding mechanism which the spec permits. 

The example shown in the cited note was the output of a processor which
implments an algorithm similar to that which is described here. The algorithm
is not original. It is that used in symbolic processing systems for decades to
manage symbols. The problems discussed in this forum arise where one attempts
to manages the qualified names as strings rather than as symbols. 

> problem, and a hard design problem.  The syntactic problem is that
> of validation, but there is a clean algorithmic solution:
> 
> 1. You have a DTD that contains elements from different namespaces
>    and you know what the URIs are for those namespaces.

As noted above, attribute defaults suffice for this purpose. If they are not
available, then an alternative means of expression is necessary. A processing
instruction suffices. There are issues about the scope / extent of such a
binding, but those do not concern theoretical restrictions, just questions of interpretation.
 
> 2. You have a document that has tags from different namespaces, and
>    you know what those namespaces are.

This is specified in the proposed standard.

> 3. You want to validate the document against the DTD.
> 4. You make a list of all the namespace URIs that are in play via the
>    DTD.  For each you generate a unique prefix.

This is handled by creating named collections of symbols (known elsewhere as
"packages") identifiying them "statically" with the uri and binding them
"dynamically" to the respective prefix. Within the dtd, the scope of the
prefix is not (yet) standardized, but there is no reason it couldn't be. The
example shown is from a processor which establishes a dynamic binding within
the doctype entity and within respective external entities, where the doctype
comprises the external dtd. Other interpretations are possible. This scoping
rule suffices, as it is both clear and effective.

> 5. You preprocess the DTD, rewriting all the element & attribute
>    declarations with the appropriate prefixes

This is handled by interning qualified names as symbols in the respective package.

> 6. You preprocess the instance, making all namespace prefixes
>    explicit (no defaulting), declaring all the namespaces on the root
>    element, and using the same set of prefixes you used in the DTD

This is handled the same was as 5. 

> 7. You validate

Yes, and exactly as if there were no explicit qualifications.

> 
> OK, this is a bit tedious but contains NO ROCKET SCIENCE.  The

It is neither rocket science, nor is it tedious. Lisp systems have been doing
it for decades.

> syntactic problems of validating in the presence of namespaces are
> just not that hard.
> 
> Now, on to the difficult problem: how do you go about making that
> DTD I mentioned in step 1, that has the combined elements?  Right now
> we have little in the way of technology or automated procedures or even
> industry experience to aid us in designing that compound DTD in a good,
> clean, and efficient way.  That's a hard problem and one that some
> of the schema proposals are feeling toward a solution for.  But we're
> nowhere near knowing the answer.
> 

This problem has two aspects. One is hard, but has nothing to do with namespaces.
One does have to do with namespaces, but is neither hard, nor is one
proceeding without "industry experience" when solving it in the context of
document markup.

The hard problem, that of combining element models, is independent of
namespaces since it arises as a consequence of expressing relations (eg.
"inheritance" or "subtyping") between element "types" and is independent of
the presence of multiple namespaces.

The problem which has to do with namespaces, that of establishing unambiguous
names, is easy. (see above).


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)