Re: [Parameters] specifications feedback

Hi, Nico-

I'll send a technical response later, when I've synthesized this 
cohesively with the other feedback and with the original specification. 
  This note is just an acknowledgment to thank you for your detailed 
comment.

I encourage anyone interested in the Parameters spec (or any other spec, 
of course) to send comments to this list.  Even if the SVG WG doesn't 
respond immediately, we take all feedback into account, and will respond 
as soon as we have a good response. :)

The Params spec is on the back burner right now, for the next month or 
so more, but I will be picking it up again soon, so please do send in 
feedback for me to incorporate and consider.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs


Domenico Strazzullo wrote (on 3/9/10 7:54 AM):
> Hi,
>
> The SVG Parameters spec seems all good to me. It responds well to the
> declared objectives of "... a declarative way to incorporate... a single
> resource, and reuse it several times with specified variations...
> without the use of script."
>
> Definitions:
> type 1 - developers who know how to code and who use code extensively
> type 2 - other content authors
>
> As a general rule it is true that the use of params needs to remain
> simple enough and intuitive, however, I think considerable thought
> should be given to the multiple implications, whether immediately
> apparent or not, as well as to those that may result from possible
> evolutions, so as to avoid the risk of generating a cumbersome and
> obnoxious heritage. Given the stakes, I would warmly recommend to let it
> cook the time that it needs. The design should spontaneously result from
> the evaluation of ALL the implications. The many past bruising
> experiences in several domains of computer and web technologies are
> revelatory and I think it's about time to make that trend a thing of the
> past. At this stage, params seems rather well born. The idea of this
> type of public discussions in symbiosis within a WG seems excellent.
>
> I find the examples talkative and immediately accessible. We need to
> consider that the general public for SVG may grow exponentially -the
> content authors as well as the end users- and this would probably
> include designers and children. The barchart example is very appropriate
> in that respect. We must bear in mind that the objective declared is to
> address type 2, who have been notoriously frustrated with their
> limitations in respect to scripting. While type 1 have always had the
> means of serializing their objects and override properties, type 2 never
> had them.
>
> 4.1 Interface Parameters
> The paragraphs marked in yellow.
>
> I have a few questions. Must we always sacrifice to the altar of
> security? For what reasons? On what grounds? Are the risks of the
> nuclear war type, at least? Can we put an end to this excessively
> zealous prevention plan that has already caused too much damage to
> society? It is the responsibility of a bank using SVG content to ensure
> the correct level of security. Instead of preventing I would recommend
> that incompetent technicians be fired -as simple as that- and replaced
> by qualified engineers, rather than have the whole system hijack the
> population with imaginary security threats. Face it, 99% of the virus
> myth came down to be motherboard or other hardware issues, while the
> establishment has had all good -to them- reasons to entertain that and
> other myths. By 99% I mean 99% of the public reactions when facing a
> system malfunction: "I've got a virus". As a good citizen I have the
> moral obligation to fight those who leverage on the latent paranoia of
> many young as well as many among the general population for commercial
> interests (I don't mean by that that those who don't feel they have the
> same moral obligation are not good citizens). SVG does not want to serve
> the merchants of fear. Also, to make an allusion, but by no means in
> relation to what I just said, normally you put a guard outside of a back
> door, not inside. As stupid as it may seem, this thought is worth
> considering, as to the dramatically different implications suggested by
> the different angles of view.
>
> That said, perhaps reasonable compromises can be found?
>
> I would like to stress out that a read-write interface is essential. Not
> implementing such an interface could preclude the eventuality that
> Params will be in effect used by type 1 who are, I suppose, the
> majority. I believe that a read-write interface would unveil tremendous
> possibilities. If it was already available I could use it in a scenario
> where I had to develop another kind of hook, necessarily unofficial.
>
> I can present the scenario.
>
> Please, consider this: over time, type 1 have developed more or less
> efficient programmatic ways to control the appearance and geometry of
> their objects in an industrial environment. The tools at their disposal
> being mainly CSS and/or DOM methods, both having their advantages and
> limitations, but neither allowing total and true OOP. The reproaches
> that I have to formulate in respect to CSS are many -they have been
> exposed on several occasions by others, to which I subscribe- and cover
> basically its limitations. Some DOM methods or properties may be
> cherished by most type 1, including myself, but are nevertheless hacks.
> CSS, as relating to SVG, is a mega hack. But... it has been very useful.
> Yes, but why? Because a Presentation Attributes Sheet type of thing was
> never designed. This is not a criticism, just a simple finding.
>
> During the last two years I set out to rewrite GEMï following a class
> inheritance model, and as using an internal library, to make it Open
> Project ready. To conform to the current writing standards I have opted
> for what is known as OOP writing techniques, which I hope some agree is
> in no way sufficient to say that an application uses OOP in effects.
>
> Then, one year ago, I was commissioned to write a SVG controls library,
> which gave me a terrific opportunity to investigate more deeply the
> matters and carry out a diligent and exhaustive study. The results of my
> research confirmed somehow my expectations and intuitions. Moreover,
> once started writing, I realized the invaluable benefits of the
> crossfire and feedback between the sort of Lego box represented by the
> library and the system represented by GEMï. Then the question became
> apparent: can I really, as type 1, reach B through A? More precisely, is
> A capable of supporting the systemic intelligence required by B? The
> answer was: A must be designed so that it can support systemic
> intelligence, fault of which it remains a Lego box to play with, like
> many others.
>
> At that stage I could finally investigate on a concept that I always
> wanted to grasp better, i.e. an object property in javascript can be
> converted to a string, resulting in the common but obscure statement
> that the "array notation" can be used instead of the dot syntax. This is
> not false but has always been put the other way round, presented as
> secondary, overlooked and rarely seen (typing laziness? Negative Java
> and C++ heritage? Fake snobbery?). The reality is very different, a
> javascript object property can be a string OR a js variable/property
> name, and this gives to javascript way much more power that it has
> generally been admitted, together with the possibility of using FP, that
> Java hasn't.
>
> As a proof of fact I take the param.js script. Doug, you are declaring
> there paramArray as an Array and then right below you use it as what has
> been commonly and wrongly identified on good books as an associative
> array. This is flatly wrong. The associative array, as compared to PHP
> arrays, is a mystification. You are really using an object in a very
> straightforward manner:
>
> var param = {}; // make it top level or namespace protected, not local!
> .
> param[ name ] = value;
>
> You are declaring an object property name as a string. Licit. param was,
> is and remains an object in its own right.
>
> But more, if and when Params is implemented and hooked, as it should be,
> then name, value and others need to become properties:
> params[name].value, .
>
> As a sidekick, with an appropriate internal conversion mechanism this
> could be expressed as params.name.value and skip the Frames or Images
> arrays type of idea, although I have no problem with that.
>
> myObject1.x = params[name].value;
> myObject2.x = myObject1.x + myObject1.width
>
> I don't mean to say that this needs to resolve (and always supposing
> that myObject1 and myObject2 are direct pointers to objects in the DOM
> tree) -although if it were for me I would contemplate to force this to
> happen (I know, it's a tremendous amount of work)-, we would still
> setAttributeNS() to make it happen.
>
> OK, back to our muttons, as the French say, asking you to be patient as
> I need to go through apparently unrelated subjects before reaching the
> final concept. So there I was, with needs to cope with and no model to
> follow. I set myself to write a pseudo language. I saw all the other
> libraries that have just that. Then I said, hold it, they don't have a
> library, they're dealing with html. All this time we, type 1, like
> little lambs, have been making constructors for primitives and all other
> elements that existed already!! No no no, I have a library (any SVG
> implementation), I just need to ask.
>
> The reasoning:
> 1) The request mechanism needs to be simply an interface through which
> type 1 can pass an object.
> 2) Nobody needs to know what the properties of this object are or claim
> to be.
> 3) The library expects to be told by the interface "what" type 1 needs.
> 4) The library and the interface are not responsible for what is
> declared, just like when type 1 or 2 write plain SVG.
> 5) The interface only needs to be intelligent enough to give some basic
> instructions to the library.
>
> The deduction: to build an argument object using SVG attribute names for
> its property names, where those names which contain illegal javascript
> characters for variable/property name will be property names in string
> format (which by the way could also be used for any name for
> consistency); to define 1 pseudo-attribute as property name to satisfy
> point 3 above.
>
> var g = $C({
> element: "g",
> id: this.id + "_spectrumGroup",
> "clip-path": "url(#paletteClip)",
> cursor: "crosshair",
> appendTo: this.group
> });
>
> Incidentally, I found useful to create 2 more pseudo-attributes as
> facilities: appendTo, which does what it does, and textNode which can be
> assigned in a text object. They are not mandatory. element is mandatory
> of course.
>
> this.spectrumMask = $C({
> element: "rect",
> width: this.width,
> height: this.height,
> fill: this.fill,
> appendTo: g
> });
>
> This is the interface (node builder):
>
> createElement: function(o) {
> for (var p in o) {
> var value = o[p];
> switch(p) {
> case "element" : var element = document.createElementNS(gemi.svgNS, value);
> break;
> case "textNode" : element.appendChild(document.createTextNode(value));
> break;
> case "appendTo" : value.appendChild(element);
> break;
> default : element.setAttributeNS((p == "xlink:href") ? gemi.xlinkNS :
> null, p, value);
> }
> }
> return element;
> },
>
> (This is LGPL and anyone who would like to use it, please, download the
> file from DC with the credits. Thanks)
>
> The call can be volatile, with no reference:
>
> $C({element: "circle", ...attributes...});
>
> Apart from this method, the classes can use a complementary prototype
> method that serves a particular mechanism: the classes only have a
> relevant set of rendering prototype properties; type 1 or another class
> soliciting an instance from said class can of course override the
> properties but can also declare in their argument object any other
> property, as attribute, that they may wish or need, when requesting an
> instance. This allows the prototype of said class to remain free of the
> overhead burden of carrying any properties corresponding to SVG
> attributes with initial values. As a consequence the instances of said
> class do not redundantly carry (pass) those attributes for their
> elements. Instead, an "extra" object -a prototype property- initially
> empty is queried and anything found in that object is integrated in a
> transient object. Since the constructor, or more precisely one of its
> specialized methods, will not be aware of the meaning or number of such
> extra properties, it passes the transient object to the complementary
> prototype method for compilation:
>
> this.mask = $C(this.attList(element, maskAttributes, this.buttonGroup));
>
> In this way the argument object passed to the interface node builder can
> be compiled by hand or programmatically, and even defined somewhere else
> in the script or in another file.
>
> These methods, combined with the overriding facilities provided by
> Params could expand their scope and become more powerful.
>
> Parallel to this I had a skin engine, and then it was only natural to
> apply the same criteria to it. I set in the skin object a collection of
> properties that would act as selectors, then have the prototype
> properties of the classes point to those selectors. That way I, as well
> as type 1, would use (what I call) the skin as we'd use a style sheet,
> never needing to go hack the classes, with some tremendous advantages:
>
> 1) multiple definitions of the same selectors in a single file
> 2) selectors' properties take references, expressions and functions
> 3) cross-reference with other classes/selectors
> 4) access to the namespace object, the superclass and the subclasses (or
> to anything, really)
>
> This is possible because a skin is an object, named
> gemi.presentationAttributes, produced by a method. The method doesn't
> expect parameters and uses properties defined in gemi.settings.public in
> a config file, which then get processed according to cookies contents.
> At this stage it gets a little complicated to expose the mechanism
> without providing code evidence. Here the class selectors get built.
> They are objects very similar to CSS, where the properties have
> attribute (painting, geometrical, other) names as a general rule and may
> also have pseudo-attributes with names arbitrarily set by myself to
> satisfy the specific needs of the control classes (the subclasses).
> Gradients and patterns also get built here.
>
> Please note that fault of standard I am using a bastard language.
>
> Naturally, if the method producing the current skin could use params to
> retrieve information from, that would be great.
>
> Examples:
>
> scrollBar: {
> fill: mix([100, 100, 100], 40),
> stroke: "#D0D0D0",
> size: 18,
> type: "linear",
> cradleFill: mix([50, 50, 50], 84),
> horCradleStroke: "url(#hCradleStrokeGrad)",
> vertCradleStroke: "url(#vCradleStrokeGrad)",
> buttonStroke: mix([100, 100, 100], 88)
> },
> scrollSlider: {
> fill: {
> hor: "url(#hScrollSliderGrad)",
> vert: "url(#vScrollSliderGrad)"
> },
> stroke: {
> hor: "url(#hScrollSliderStrokeGrad)",
> vert: "url(#vScrollSliderStrokeGrad)"
> },
> 'fill-opacity': .25
> },
>
> * mix is gemi.shadeMix(), an engine producing variations on a theme,
> capable of acting on luminance as well as on hue deviations and saturation.
>
> also:
>
> frame: {
> fill: mix([90, 90, 90], 24),
> stroke: mix([90, 90, 90], -6),
> rx: 2,
> 'fill-opacity': function() {
> var c = gemi.hexToRGB(gemi.background.fill);
> var lum = gemi.luminosity(c[0], c[1], c[2]);
> return (.15 + .15 * (lum < gemi.themeLuminosity));
> },
> 'stroke-opacity': function() {
> var c = gemi.hexToRGB(gemi.background.fill);
> var lum = gemi.luminosity(c[0], c[1], c[2]);
> return (.25 + .3 * (lum < gemi.themeLuminosity));
> }
> },
>
>
> all: {
> 'font-family': "'Segoe UI', 'Trebuchet MS', 'Lucida Grande', 'Deja Vu'",
> 'font-size': '10pt',
> stroke: "#7F7F7F"
> },
>
> * "all" is an arbitrary name and is pointed at by the superclass prototype.
>
>
> background: {
> fill: gemi.settings.public.backgroundColor
> },
>
>
> text: {
> fill: (gemi.themeLuminosity < 128)? mix([100, 100, 100], 90) : "#000000",
> fillInverse: (gemi.themeLuminosity < 128)? "#000000" : "#FFFFFF",
> shadow: (gemi.themeLuminosity < 128)? "#000000" : mix([82, 84, 85.5],
> gemi.themeLuminosity / 4)
> },
>
> * text is not a class, it can be referenced by a property of any class,
> or type 1, who wishes to accord their text element(s) fill to the theme
> color and the luminosity, for example the "title" property referencing
> the text element of a dark top bar would appear in video inverse:
>
> fill: gemi.presentationAttributes.text.fillInverse,
>
> It is evident that the gain would be considerable if the objects or type
> 1 didn't need to go through all the hierarchy and bureaucracy to use
> this self-proclaimed Presentation Attributes "sheet".
>
> The two main points that justify this discussion are:
> 1) To advocate the read-write, always admitting anyway that read-only
> would already provide a lot to play with
> 2) To advocate the creation of a Presentation Attributes Sheet and to
> establish the communication with Params
>
> Relating to point 2, I would like to say that my solution is embryonic
> and offers what it seems to me a viable mechanism that works anyway like
> a swiss clock in the two applications I've been referring to.
> Nevertheless, I do realize that beyond a certain stage it is not any
> longer the matter of one person; ideas from multiple sources need to
> converge and situations need to be analyzed. Please also note that the
> skin engine has not yet been released as a sort of plugin, snippet or
> whatever, and neither of the two applications mentioned have been
> released yet.
>
> Regards,
> Domenico
>
>

Received on Monday, 22 March 2010 13:58:40 UTC