Loading ...
Sorry, an error occurred while loading the content.

Human readable? semantic web and SVG 1.1 /2.0

Expand Messages
  • r_diblasi@hotmail.com
    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
    Message 1 of 60 , Oct 15, 2001
    • 0 Attachment
      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

      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

      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:

      ......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:
      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:
      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.

      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:
      (goto message 4711 on this yahoo SVG-developers group)

      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" >
      <x id="change_this_x">300</x>
      <lineto command="closePath">

      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

      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

      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
    • r_diblasi@hotmail.com
      Tobias, ... your welcome.....I am mean that...the offer is firm....and I hope you understand when I say....If I can understand it....I will try my hardest to
      Message 60 of 60 , Oct 18, 2001
      • 0 Attachment

        --- In svg-developers@y..., Tobias Reif <tobiasreif@p...> wrote:
        > Robert,
        > thanks for you offer;

        your welcome.....I am mean that...the offer is firm....and I hope you
        understand when I say....If I can understand it....I will try my
        hardest to make learning the "technique" as easy as I can for others
        who would like to try it out.....SVG for ALL!!!! :-)
        > as far as I'm concerned, for now, I'll just play with simple XML
        > notations for CSS, and some time later post my thoughts.

        That would be great...if you choose that route ....SVG people around
        the globe I am sure would benefit from your thoughts

        > Perhaps we all put that thread to sleep, think, experiment, read,
        then try to really work on something together.
        > Tobi

        I think that is a good idea :-) ...and think that others that may
        have followed this thread or follow it in the future will learn a lot
        about the individuals on the list at this time and some of the issues
        that SVG can work towards......

        Nice Debate.......Peter....thank you for your thoughts....and thank
        you to all the others that participated .....on to other issues
        then....at least for me.....If other feel like commenting on the
        subject....please continue to chat.....I think I will sit back and
        observe and play with some new SVG toys .....and take a look at
        regular expression......

        interesting....perl keep calling me too....and servlet....Tomcat...oh
        You get the idea :-)

        We all learn by sharing what we know
        Robert A. DiBlasi
      Your message has been successfully submitted and would be delivered to recipients shortly.