David Brownell wrote:
> Actually, the quote was from me.
Oops. Thanks for the correction.
>>David Brownell wrote:
>> > >Namespaces need versioning. URIs can easily include date
>> > >codes like "02Nov1997"; W3C itself uses such a scheme, as
>> > >you can see by looking at versions of the namespace spec.
>>
>> Charles Reitzel wrote:
>> Yes, the FPI and/or URL needs versioning. With a decent namespace
>> spec,the prefix used in documents should not. The fact that the prefix
>> is, for all practical purposes, a public identifier, controlled by the
>> DTD author, and tied to a specific verion of the DTD, prevents document
>> authors from changing DTD versions without rewriting their documents.
>> - Not useful.
>>
>> The original namespace WD did not have these flaws.
>
>I don't see what you're saying. All versions of the namespace spec
>have used the URL as _just_ an identifier. The identifiers need to
>reflect an exact set of meanings, hence they need versioning. The
>prefix was chosen and used by the document author, hence needed no
>more versioning than the document itself: "this version", versus
>the case of the namespace URI (meaning defined by a third party, and
>updated/maintained/changed over time), "the version before that big
>incompatible change".
>
>That is, I don't see an issue that's tied only to the _new_ draft
>of namespace support, or even one that could be removed.
The difference is that for a prefix to be set in a DTD it has to be a #FIXED
attribute of the element and is, therefore, defined by the author of the DTD
and *not* the document. If the prefix is set by the document author, then
the exact, version-specific URL must also be included with each instance of
the element using the prefix.
In the first case, the prefix must also be version specific and, therefore,
cannot be used as a mechanism to insulate documents from changes in the DTD
version. In the second case, when the DTD version changes, every instance
of its use must be updated to refer to the new version of the DTD fragment.
Remember, the purpose here is to define standard libraries of DTD fragments
which can be used for industry specific EDI transactions, standard data
types, and the like. Such DTD fragments will occasionally undergo updates
which will be, by and large, backward compatible - much like standard
function libraries. Typically, only a small number existing elements would
be "broken" by the new DTD fragment. The document author simply has to
change the prefix declaration to point to the new version of the DTD
fragment and run the documents through the parser and/or application. With
a well designed and maintained DTD fragment, only a few elements will be
kicked out.
With the old spec, the prefix is associated with a URL uniquely within a
document and cannot mean different things for different elements. The
prefix declaration occurs in the document prolog, possibly in an external
entity (i.e. DTD fragment). Currently, the NS processing instruction is
allowed as a custom, non-standard feature and may well not be inter-operable
with other XML parsers or applications. That said, the processing
instruction is *required* for validation to work (i.e. for an element
instance to be correctly associated with its declaration by its qualified
name). But all of this ground was well-trod by xml-dev'ers when the revised
NS spec came out.
See what I mean?
Best regards,
Charlie Reitzel
Independent Consultant
P.S. I sense a great deal of hesiation among industry groups hoping to base
data exchange standards on XML DTD's due to this issue. Is everybody giving
up on validation and moving to DCD instead?