I happen to type my mail on a machine on a mac on which a backup program also
runs. Occasionally it polls network clients. Which can cause the mail editor
to drop characters. Usually they're incomplete words and I catch them. I
missed this one. Again my apologies.
> But this isn't true. It provides a facility which can be used in a
> validation compatible way (just as the original facility), and which can
> also be used in a validation-incompatible way, just like the earlier one.
> In both cases you need to know what's in the instance to create a DTD which
> will make an instance valid -- that's an ineveitable side-effect of mixing
The problem with the former version appears when one has to work with existing
DTDs and does not want to rewrite them manually. If there are tags which lead
to "name collision", the former proposal precluded validation (or led to
"trivially invalid" documents) while the present proposal permits a more
meanigful form of validation.
> ...
>
> To the extent that you are proposing a separate namespace standard, I hope
> that you are unsuccessful. It's a hard thing sometimes to buckle under to
> the fact that much of the time _any_ standard that is accepted is in fact
> better than a custom solution that is not accepted.
>
The present proposal specifies no correspondence between qualified names in
the dtd and universal names. As I read it, it does not specify that there is
no correspondence; it specifies nothing. If it were to say how a processor is
to work with the names in the DTD, I might have something to "buckle under
to". At the moment is says nothing. Which I had understood to mean that an
application could well assert such a correspondence and still conform to the standard.