Human readable? semantic web and SVG 1.1 /2.0

SVG Developers and W3 members ....others 

[WARNING]: This is an open letter to W3 working group and SVG 
Developers.  I am questioning SVG in the spirt of finding out how 
people feel. My comments may sound "rantish" but are given freely to 
the group for discussion.....this note is not directed to any one 
person in the SVG community!!!!.....but is directed at how SVG is 
coded....and with hopes of adding a new feature to the up comming SVG 
1.1 or 2.0 SVG updates...OK.....here we go.....please ask if you do 
not understand what I am tring to say....I start with font-
information and go onto the path element

<tobias-wrote>
 What bothers me is the cdata that is also being used in that it is 
not readable by humans. Grant that FLASH isn't either, readable I 
mean. But some of these great looking examples seem to be to much out 
of a black box
</tobias-wrote>

  The "font-face issue".....as I call it.....could it be solved if 
you put the font in another file.......his is possible right?.......I 
have seen this "font-junk-info" in the SVG code and I really do not 
like it!....It is totally unreadable......and really goes aginst the 
number 6 object / goal in XML 1.0 specification:
http://www.w3.org/TR/2000/REC-xml-20001006#sec-origin-goals

......heck ...I would argue that "path data' falls into the same 
category as this font important........"not well described" ....this 
is an importaint issue that I would like to discuss with SVG 
Community.....please comment.....and please look at the XML 
specification link I have provided.....and please look at this E-mail:
http://lists.xml.org/archives/xml-dev/200003/msg00199.html
and please make sure to read the follow ups.....

The point is that SVG could add some elements/attributes that a 
writers of SVG code( could be used by people who like to use elements 
and attributes to describe their code.  This could also help machine 
generated code :-) ....for example... One advantage is path data can 
be broken into parts and each part could have "id" attribute  added 
to each of the parts....this would allow the changing exact parts of 
the path data :-)......this would have several advantages....for both 
declaritive and script/DOM access :-)

Part of the the E-mail responce states:
<snip>
In recognition that path data into a single attribute makes DOM access
difficult, SVG provides a series of convenience DOM methods to access 
the contents of a <path> element on a per-command basis. You can 
insert, delete and replace commands within a <path> element via the 
convenience DOM methods.
</snip>

OK.....what about this....

First things first......what about access to X,Y coordinates? 
Some of SVG finest have looked into the problem I posed and this is 
what they had to say:
1)
  (goto message 4711 on this yahoo SVG-developers group)

2) 
  yahoo message 5289 has come up with a solution by Manuel Bauwens
  but this is not something the average coder should have to go     
  through...in my opinion!!!


   What about declaritive  ways of accessing the SVG path commands as 
I mentioned above.....not everyone is going to include "scripting 
language" in SVG file or even understand a scripting language or know 
how to control the DOM....and in my opinion or should have to know 
scripting.....I know I am being contradictory and redundant ....I 
guess I would like to see  declaritive elements and  script/DOM have 
the same funtionality when it comes to paths....This would allow SVG 
the have strength to stand on its own......and at the same time...if 
a person wishes to use script/DOM can....giving SVG the best of both 
worlds .....right from the start!!...think of the advantage of having 
paths commands described as elements when it comes to animation!! The 
animation could use xlink to target just the part of path that needs 
to be animated because it is labeled with "id" attribute....really 
easy for people who do not what to learn "all the scripting 
stuff"....and if they want to use scripting/DOM using "getElementById"
what could not be any easier :-)

[todays SVG path element and data attribute:]

<path id="path_5" d="M 100 100 L 300 100 L 200 300 z"
        fill="red" stroke="blue" stroke-width="3" />


[some concept code (just an idea....not offical version ...this code 
can be changed...and it would be great to see what people come up 
with. .....remenber this would be just another way to create 
paths....and would be very powerful when XML schema is created for SVG
think of the ability to restrain values in this code ...the XML 
parser would take care a checking :-)]

<path fill="red" stroke="blue" stroke-width="3" >
              <pathData>
                      <moveto>
                            <x>100</x>
                            <y>100</y>
                      </moveto>
                      <lineto>
                            <x id="change_this_x">300</x>
                            <y>300</y>
                      </lineto> 
                      <lineto  command="closePath">
                            <x>200</x>
                            <y>300</y>
                      </lineto> 
              </pathData>
</path>

This idea leads to every element can have a "id" attribute!....notice 
that within the first "lineto" element...there is a "id" 
attribute: "change_this_this_x".....very easy to access and 
animate.....with script/DOM or declaritivly think about it!!

Chris, Tobias, Mike, Jon, Peter, others.....before SVG 1.1 or SVG 2.0 
goes too far.....I think it would be nice to address these issues 
again please :-)

By the way how do I submit a suggestion to SVG 1.1 /2.0 working 
group....

a little rant from the mind of an XML idealist :-)......The semantic 
web can work if we give it a chance!!......but for it to 
work ....need to describe everything idealy........not try to shove 
all information into one attribute because it makes file 
smaller........really throwing SVG into question as a XML 
format....path data really is just a flat file formate in an XML 
attribute.

Question: 
How come path attributes (commands) can not be described both 
declaritivly and in the form path commands are in now? I do not see 
the problem.....and can only come up with solutions.......

We all learn by sharing what we know
Robert A. DiBlasi

Received on Tuesday, 16 October 2001 16:41:06 UTC