[standards-jig] UPDATED: Icon Styles (JEP-0038)

Richard Dobson richard at dobson-i.net
Thu Mar 6 00:13:25 UTC 2003


I think that the proposed changes should really be made now rather than
later exactly for the backwards compatibility concerns cited, it will be
much harder to change things later on such as the IMO very good suggestion
of object instead of separate graphics etc bringing it inline with other
major standards, also since the JEP is only experimental and not even draft
developers took the obligation when they implemented the JEP to adopt the
final standard once decided so I think using the "backwards compatibility"
reason at this stage is irrelivant since there isnt an existing standard for
this JEP to be backwards compatible with.

Anyway, so overall I say make the hard/major changes now before they cause
serious problems later.

Richard

----- Original Message -----
>From: "Adam Theo" <theo at theoretic.com>
To: <standards-jig at jabber.org>
Sent: Wednesday, March 05, 2003 9:46 PM
Subject: Re: [standards-jig] UPDATED: Icon Styles (JEP-0038)


> Yes, This update is really just a polishing off of the previous lines of
> thought. It is backwards compatible with the many existing
> implementations, which was the deciding factor when I was choosing
> whether or not to include the changes proposed by Mattias and others. I
> decided I would juyst keep the specification as-is, and let the Council
> decide whether the proposed changes were important enough to include in
> the final spec.
>
> The points that Mattias brought up are briefly addressed in the "Future
> Considerations" section, which suggests using future revisions and JEPs
> to add on or change the specification as it exists.
>
> This is the first I've seen of Mattias' page listing his proposals. I'd
> just read them on the mailing list. It looks like a good summary of the
> concerns against the current specification. If the Council decides they
> should be included, I don't have any problems doing so. I just left this
>   spec as-is for the sake of backwards compatibility for existing
> implementations.




More information about the Standards mailing list