RE: .webfont Proposal 2

On Thu, 2009-07-16 at 19:26 +0000, Sylvain Galineau wrote:
> >-----Original Message-----
> >From: Thomas Lord [mailto:lord@emf.net]
> 
> 
> >Such solutions work well for some applications,
> >that's true.
> 
> Why they would work less well here remains unexplained.


Perhaps to some, including yourself.


> >> I honestly don't
> >> know how I would convert a directory to MIME on any of them or why I'd
> >even want to do it;
> >
> >You normally would not or want to do so.  Normally
> >you would want to use a file archive tool and format
> >that records file meta-data such as modification time.
> >
> >MIME is a good choice for a meta-data wrapper, though,
> >because it is flexible, already extensible in an orderly
> >manner, and parsimoniously consonant with the design of HTTP.
> 
> That it is a good choice does not make it better for this purpose or any other.

Which is why other arguments are added.

> Asserting its conveniently ill-defined 'parsimonious consonance' is unhelpful.
> Why this is a relevant criteria and how to measure it is also unexplained.

Perhaps the message I sent just prior to this 
in reply to Bert Bos will help you.  I address
"consonance" in that.



> The fact that MIME is not widely used for this purpose today should indicate that such
> 'consonance', however relevant it might seem in theory, is not so in practice.

You are simply mistaken.




> >> nor did anyone ever send me a file archive as a collection of MIME
> >parts vs. a single zip.
> >
> >Typically people send files as email attachments.  Your
> >Mail User Agent is acting as the encoder / decoder,
> >as I'm sure you are aware.
> 
> If MIME was so well suited to encoding file archives, 


No one has claimed that it is or that "encoding file
archives" is the task at hand.

> one would expect
> internet mail clients to expose such a feature and do so routinely since it is
> a very common scenario in practice. That they generally do not and zips are
> generally used for this purpose is a valid data point imo.

It is not an untruthful fact, certainly.

MUAs typically let users attach various files but
do not try to replace, say, "tar" or "zip".  
That's quite true.


> >Either solution can "technically work" but they
> >make distinct trade-offs.  I've explained why I think
> >the MIME trade-offs are more appropriate to the design
> >context.
> 
> You have merely asserted it was more appropriate and backed up your assertion using
> more assertions.

W3C and other important collections of standards generally
use the mime media types to name media file formats.
The burden is on you to show why this case should be 
different.


> >> So, fwiw, I don't think parsing and decoding MIME adds
> >> any value here
> >
> >As I explained, among the relative advantages are
> >parsimony (c.f. HTTP), orderly extensibility, and
> >the avoidance of unneeded meta-data fields.

> Each MIME part requires header data that would be unnecessary with a zipped archived


I have nothing further to say to you in a civil tone
at this juncture.


I have difficulty accepting that you are making these
arguments of yours in a spirit of intellectual honesty.

-t




> so it is unclear what metadata is saved, how much is saved, or why this type of metadata is
> worth saving more than this other one. Why any of this is relevant to this specific proposal is
> also unclear.
> 
> Also unclear is what is 'disorderly' about the extensibility of the alternative, when, how and why that is
> a criteria for this proposal, how MIME addresses these specific scenarios and does so in a clearly better
> manner than anything the current serialization could achieve.
> 
> As for the importance of these alleged advantages to the success of this proposal, it is asserted but not
> demonstrated.
> 
> >> and I don't buy that
> >> 'consonance with the design context' mandates standard
> >> internet mail encoding for web fonts at all.
> >
> >It is clear that you do not but why or why others
> >should agree with you is unclear.
> 
> Since you're the one demanding a change, it is up to you to obtain agreement from
> authors and implementers. As I have no objection to this part of their proposal, I
> surely have no need to get agreement from them.
> 
> >
> >> The proposed solution makes it much simpler to
> >> create these files, edit them, and generally
> >> handle them both manually or programmatically.
> >
> >Do you envision, for example, people creating
> >a font for web use, writing the metadata file,
> >and then using, say, a "zip" program to package
> >the results for distribution on the web?
> 
> Zip archives are so common it does make it easy for web authors to
> examine such files, for developers to debug, for admins to audit them, as well
> as easier for tool vendors to support them given that many already support
> similar formats. From JARs to ODF to KMZ and many others, the practice is very common.
> 
> Implementers and users alike are likely to prefer 'consonance' with common real-world practice
> over unclear and largely theoretical benefits stated by one individual. No one needs to make a case
> that the proposed serialization scheme works well in practice. You, however, need to make a compelling
> case that your alternative will work much better than this common practice and why. I suggest that
> repeating assertions of 'parsimonious consonance' will be unhelpful in making that case.
> 
> >
> >Among the disadvantages of such a plan is that on
> >most systems, the ordinary way of creating such a
> >file archive or unpacking one will record and restore
> >file attributes such as a user ID.
> 
> If one expects that most people will rarely, if ever, create such files
> then this implementation detail should be of no concern.
> 
> >
> >It is a simple enough matter, on the other hand,
> >to write an "encode/decode" program pair for a
> >MIME format.
> 
> Encoding MIME is trivial. Decoding it can be, however, a lot less so as anyone
> who ever had to parse real-world MIME data knows. One could simplify this by
> defining a very strict MIME profile for web font purposes - e.g. 8bit encoding only, limited header set -
> but that is extra spec and design work beyond the current proposal, it will require specific encoders
> to be written etc. Solutions that require more design work as well as more code to achieve interop
> ought to be less interesting than alternatives that do not.
> 
> >
> >
> >> Lastly, I don't think a web font format should require
> >> client software that wishes to support them to include
> >> a MIME parser (HTTP is MIME-like but not strictly
> >> MIME-compatible).
> >
> >I am at a bit of a loss as to why you think
> >MIME is unacceptable while, say, zip is not.
> 
> I never said it was 'unacceptable'. Zip archive formats are widely supported and used
> by many applications for similar purposes. We know from experience the pattern works well,
> and the professional user base who will deal with those resources in their daily work
> is already both familiar and comfortable with it. As I am not able to make any of these
> claims about raw MIME archives, I am bound to be less comfortable with it than I am with using
> a simpler, very well established pattern.
> 
> >It is unclear what you propose to form agreement
> >about.  The phrase "structure and content" is vague
> >and you seem to specifically exclude serialization
> >from being an aspect of "structure and content".
> 
> Orthogonality does not mean exclusion. Serialization does not matter if font vendors
> are not interested in this proposal and no browser vendor wants to implements it. These are
> the high-order bits.
> 
> I will therefore not discuss this issue further unless someone demonstrates clear purpose and benefits
> to making this change. It doesn't appear you can make this case.
> 
> 
> >Perhaps it would be more effective if you offered up
> >a specific proposition to which implementers, foundries,
> >and the larger community, could express agreement or
> >disagreement.
> 
> I suggested leaving the proposed serialization as is. MIME adds nothing and costs much for no good reason. I don't
> know how to be more specific than that. But if you're saying that the only reasonable way to disagree with you is to
> make a full format proposal *and* get it accepted, then I suggest that parsimonious consonance with humility
> may get you a lot further than MIME :)
> 
> 
> 
>

Received on Friday, 17 July 2009 02:12:01 UTC