dev@glassfish.java.net

Re: DTD name changes and the DOCTYPE

From: Bill Shannon <bill.shannon_at_oracle.com>
Date: Fri, 28 May 2010 23:44:48 -0700

vince kraemer wrote on 05/28/2010 11:17 PM:
>>> There's all kinds of things that can change incompatibly during the
>>> process of designing and building the release. Developers should
>>> expect that.
>
> yes... but there is no reason to create a situation which makes it
> easier to create (or may even necessitate) an incompatible change during
> the release cycle, when it is drop dead simple to avoid it...

Well, I agree that we shouldn't choose names that we *expect* will
change, but beyond that we're just rolling the dice on whether any
change to the content will be incompatible with previous instances
of the same-named DTD.

>>> If they want stability, use a released final product, or at least use
>>> the
>>> descriptors from a released final product.
>>>
>>> Even if we pick the names for these DTDs now, and never change them for
>>> the rest of this release, we're *still* not committing that each change
>>> we make to the DTD will be completely upwards compatible with the
>>> previous
>>> intermediate version of the DTD.
>>>
>>> The tools, for instance, absolutely should not be generating descriptors
>>> that match these new DTDs by default. Use the old DTDs, they still
>>> work.
>> But if we want to encourage users to start using the new
>> glassfish-*.dtd and move away from the sun-*.dtd, the tools probably
>> should use the recommended set of the dtds? Also if there are new
>> elements introduced in 3.1, the tools want to make them available to
>> the users too?
>
> And developers creating dev tests and qa folks creating functional and
> system tests and early adopters/evanglists creating demos and...
>
> There are many folks that have legitimate use-cases that precede the
> general availability of GlassFish Server 3.1 that I want the dev builds
> of NetBeans have 'supported' in the past

It's fine for a non-final version of NetBeans to support a non-final
version of GlassFish. I would still be cautious about using the
non-final DTDs by default, but I guess that's your choice.

I suspect a lot of people use the dev builds of NetBeans as just a
better bug-fixed version of the previous release.

>>> If you need to use the new DTDs, expect them to change until the code is
>>> frozen.
>
> I expect them to change. Early adopters expect them to change.... But
> we do not need to set-up a situation where they should change, when we
> could have avoided the issue completely...

I agree. But as you're seeing, there's some instability as we work
out what we *should* be doing. If we were much better at this, and
could plan everything in advance before doing anything, we might be
able to avoid that. But...

>> Yes, agreed. There is always chance of them changing between now to
>> code freeze.
>> What about we use "-1" at the end for all the glassfish-*.dtd? The
>> contents could still change, but there will be less chance for
>> incompatible changes when adding new elements, and we could make
>> things a little easier for the tools.
>>
>
> Again... why do we want to go from non-existence to "1", instead of
> "0"... None of the glassfish-FOO_X_Y-Z.dtd files existed in a previous
> release...
>
> In all the previous cases we have started with sun-FOO_X_Y-0.dtd and
> then created a sun-FOO_X_Y-1.dtd when we added elements/attributes to
> the grammar defined in sun-FOO_X_Y-0.dtd that has been released.

It's all about what people will expect. If people think of the new
DTDs as just updated versions of the old ones, where the update is
to change the name, then "-1" makes sense, because of course any *other*
update would've also changed "-0" to "-1".

If people think of it as we're just renaming them, and the name isn't
*really* part of the content, so we're not really "updating" them, then
keeping them all at "-0" makes sense. But then if we do change the
content, do we bump it to "-1" and remove the "-0" version with the
new name? Seems like we should, if this is how you're thinking about
it.

Or, if you think about is as just introducing some completely new DTDs,
unrelated to any of the old DTDs we supported, then obviously they should
all start at "-0", no matter what the content is.

I'm not claiming that any of the above is "right" or "wrong". I'm just
pointing out that there's different ways of looking at it that lead you
to different conclusions.