On Tue, 11 Mar 2008 22:00:27 -0400, Linonut wrote:
> * Erik Funkenbusch peremptorily fired off this memo:
>
>> On Tue, 11 Mar 2008 15:27:43 +0000, Roy Schestowitz wrote:
>>
>> As far as you know. Uh huh. Never mind the fact that virtually every
>> "standard" in computers includes at least some "implementaiton defined"
>> features. Search the C and C++ standards, for instance, for what's
>> implemenation defined. There's a lot.
>
> There shouldn't be anthing that's undefined in a document format, however.
What part of "implementation defined" do you think means "undefined"?
> For example, consider images. The specification should, in my opinion,
> allow only specific known image formats to be included in a user
> document. That way, no vendor's private binary bullshit can be added,
> and thus no vendor can use their private binary bullshit to lock the
> document away from other implementors of the specification.
>
> If a new image format comes along, the format can be approved and added
> to the specification.
Uhh. yeah. So users have to wait until a standards body decides to add a
new format, then they have to wait for the vendors to implement that
formant, making it years between when the format appears and when it's
usable in documents.
> The reason for implementation-dependent stuff in C is because machine
> architectures differ. There's no reason for implementation-dependent
> stuff in a document specification. Not for binary data formats, and not
> for making a document look exactly like it might look in a legacy
> document-format vendors proprietary format.
If you make the standards coverage too small, you essentially kill
interoperability because everyone has to create their features as
extensions.
> That's my opinion, anyway. The harder you make vendor lock-in, the
> better.
Actually, what you describe would make vendor lock-in even easier, since
there are far fewer things defined in the standard, vendors will have to
exten the standard to get the job done, thus lock in.
|
|
