RE: WOFF and extended metadata

From: Levantovsky, Vladimir [mailto:Vladimir.Levantovsky@MonotypeImaging.com] 

>With the level of scrutiny that was applied to the draft spec, the review process conducted by the WG can hardly be characterized as "rubber-stamping". Sylvain, you among many other members of the WG provided valuable > comments, and this particular discussion is the direct result of it. I agree with you that mischaracterizations are unnecessary, including the allegations of "rubber-stamping".

With respect, being repeatedly told that my feedback comes too late, that 'there is no discussion' about something because all the stakeholders have already approved it etc. does not convey the impression that feedback is really sought nor that change is truly desirable, if possible.  

> ...yet you seem to be asking for a proof that this format and its usage already exist. 

I am being *told* it does exist, and that it is a reason why we should not change certain things. So I don't 'seem' to be asking. I *am* asking based on the information given. 

At a minimum, I expect that a format designed with input from foundries has been at least hand-tested on a bunch of ways using real/imaginary products. Such samples are important to document use-cases and usage. We need them. The spec, imo, needs some of them as well. Good informative examples and use-cases are very worthwhile.

> Speaking from my own experience: I know many things - one of them being that there are many more things I don't know. 
> I would speculate that this is universally true for everybody - this is exactly the reason why I (and many members of this WG) believe the extensibility is so important. 
> What we know today can be documented in the spec; it is what we don't know that will become use cases for metadata extensions.

You cannot design for extensibility in a complete vacuum. You can't just say 'and here is the place where extensibility magically happens'. That's silly. While you can't predict all the things people will come up with, you add extensibility based on at least a few scenarios. Because until you have some you can't possibly design an extension mechanism with any degree of confidence that it will actually be useful for anything at all. I never asked or expected anyone here to document the entire universe of future needs. It doesn't mean that there is no value in inventing *some* based on what we know today to get us started. 

> We have already agreed that any "random" or "arbitrary" XML should be ignored, there is no reason to bring this up times and times again. 

I was told my argument was all over the place. Do you mind if I outline the sequence of events as it happened ? :)

> No one, really? Don't we all dislike "mischaracterizations"? :)

I came up with the EU/Adobe hint example. How many use-cases for the extension area have come up before yesterday ? Given the number of people qualified to come up with useful examples in this group, I do not believe this was a mischaracterization.
 
> Fonts by their very nature are tightly coupled with languages and writing systems. The communities who speak *minority* languages are going to benefit the most from this development - this is why localization of metadata > is so important. 

It's an argument one could make about any kind of metadata format. People speak multiple languages therefore property names should be translatable.  Well, not quite; use-cases first please. So we understand how much localization support is likely to be necessary for the scenarios we know of, instead of assuming that everything needs its own separate language matching and what not.

> The keyword here is "mutually" - yet you Sylvain sometimes seem to contradict everyone including yourself.

Please be specific. Where I contradicted myself, and *why* it happened. When the input changes or  the process gets stuck, I may have to change my mind. Should I stubbornly stick to the same thing in the face of evidence, or lack thereof ? Would that really be better ? In the absence of actionable input allowing substantial progress to be made, what options do I have but fall back on the original status quo ? It doesn't mean I like it. It means I'm stuck. My apparent contradictions only reflect the nature of the discussion e.g. I was first told extensions would be defined using arbitrary XML which could be rendered using XSL transforms or equivalent etc. Then I'm told extensions must support localization according to a pattern already established in the specification. Which implies the XML could not be arbitrary in the first place.  I am bending this way and that because that is what's going on, Vlad. Believe me, I'm not jumping left, then right, then back left by choice or because it's so much bloody fun. 

> May I remind you that we are only two weeks into this development and, given the progress we made, it's pretty impressive what this WG can accomplish. Your input is valuable and very much appreciated - let's keep things > positive, negativity doesn't help anyone.

No it does not. And I don't take the failure to make progress on this topic - the mail volume/progress ratio being pretty horrible imo - as anyone's but my own. 

I don't think I understand the problem any better now  than I did two weeks ago. That's a pretty poor return on the effort so I'm happy to let others have a go at it. I've frankly had enough of jumping  through every other hoop and being told I shouldn't jump so much. I think I've spent more time arguing the design of this feature  than it should take a summer intern to code it if it was designed with implementation in mind. 

Add to that that it's an optional feature and I can't justify spending any further time on this topic at this point. Sorry.

Received on Wednesday, 9 June 2010 23:26:21 UTC