Copyright © 2003 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This document lists the design principles and requirements for the creation of a SVG specification related to Templates.
This is a W3C Working Draft for review by W3C Members and other interested parties. It is a draft document and may be updated, replaced or made obsolete by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of current W3C Recommendations and other technical documents, including Working Drafts and Notes, can be found at http://www.w3.org/TR/
This is the first release of the SVG Template Requirements. It is expected that this document will progress through a number of working drafts, including "Last Call", before being published in final form.
This document was developed by the Scalable Vector Graphics (SVG) working group as part of the W3C Graphics Activity. The authors of this document are the SVG Working Group members.
Feedback on this document should be sent to the email list the public mailing list of the SVG Working Group (list archives). To subscribe send an email to www-svg-request@w3.org with the word subscribe in the subject line.
The latest information regarding patent disclosures related to this document is available on the Web. As of this publication, the SVG Working Group are not aware of any royalty-bearing patents they believe to be essential to SVG.
This section represents the status of this document at the time this version was published. It will become outdated if and when a new version is published. The latest status is maintained at the W3C.
The SVG specification is a W3C recommendation that describes two-dimensional graphics in XML.
The following key words and phrases used throughout this document are defined here for clarity. The terms Must, Should, and May are used to specify the extent to which an item is a requirement for the SVG working group in defining SVG. These recommendations should not be mistaken as a guide to implementors.
The following usage scenarios illustrate some of the ways in which SVG Templates might be used for various applications.
Insert Use Case 1 Explain use case 1.
Insert Use Case 2 Explain use case 2.
Memory and processor requirements What are the requirements on memory or processing resources?
Implementation commitments How difficult, or what details are needed, for implementation?
Ease of authoring What considerations need to be borne in mind for authors?
The authors of this specification are the participants of the W3C SVG Working Group.
Connectors
DS: we have in the past talked about this
... i want to briefly go over some use cases for connectors
... and details
... we've avoided connectors because you can graphically represent something connecting something else
... but it doesn't have a logical connection
... there are a lot of use cases for things that are logically connected
... circuit diagrams, flow chart diagrams, any kind of node-edge graph
... we've avoided them in the same way as avoiding default symbols
... so connectors could also be used for representing roads, or any kinds of routes through some thing
... i think the class of uses for these things is large
ED: xlink:href on every element?
DS: there are a number of approaches
... i think the basic idea is that there are two aspects to it
... one, a logical connection, between two elements which represent two different objects
... and one is a physical connection
... an obvious thing people would like to do is [draws on board]
... [two circles connected by a line, moving one circle should make the line follow it]
... that could be done in the very simplest case, but i don't think people are going to want
to do something where the line has to wrap around another shape, for example
... implementors aren't going to want to solve that case
... edge routing
... but i think there is still a lot of utility in straight line connections
... in the future, potentially allowing the author to say "go through this point" when routing
CL: this needs to be a new curve type?
DS: could be just straight lines
... solve many use cases, not all
CL: curves that pass through particular points we've come up against before, so perhaps we want to add them
DS: making a rendering element is one aspect of the problem
... making a logical one is another aspect
... so are these connections directed, undirected?
... that's part of the logical aspect of it
... another part is "what is the relationship itself"
... e.g. does that mean parent--child relationship, or what
... that might be represented as a form of metadata, like rdf
... or it might be, for a UI, some textual equivalent of that equivalent
... if i'm following a map, so you walk from the subway stop to the building
... maybe the metadata is "walk from from subway stop to building"
... how would you express that? maybe you'd have a <title> element
... how do you represent the connector
... i'm positing that we need a 'connector' element
... what characterstics does it have?
... it has a from and a to
... so a connector, as i see it, is a special form of path that doesn't have a fill
... what i'm thinking is that it would take path syntax so that if you wanted to do your own routing,
you could say this is what it looks like
... another way i thought of doing this would be to have role="connector" on a path
... and that would mean logically that it is a connector
... if connector weren't implemented, you could represent it as a path
... what is the role of a connector? either as a separate element or a path
... it's to present to a user to go from one thing to another
... pretend we are in a flow chart, and we're navigating around it
[draws on board]
scribe: if you're in one node, and you want to navigate to another node that is connected from that one
... the tilte of connectors could be read out, for example
... and the user could choose
... or maybe it's a popup that lets the user see what the relationship is
... in terms of navigating documents in a logical order, a blind person could query the connector to find out where it's going
... so they could step through a complex diagram
... one use case i've seen for this is that they wanted to have all of their wiring diagrams for cars as svg files
... apparently in japan, wiring diagrams for cars are done in svg
... so when a mechanic is trying to sort out "is this circuit live or not", we set up a little animation
to show them if they clicked a button which connectors are active
... so in this scenario you might write a state machine and enable/disable certain connectors
... it would be an accessible way to present these diagrams
... right now, if i were navigating these elements, in 1.2T we could use the nav-* properties
... but they only solve a physical case
... with the connectors they define implicit navigation options
... maybe its role would indicate the direction of the connector
... so there's also a visual aspect of the problem
... we should reuse existing path syntax, so if a person wants to do custom routing they can
... failing that, it would just be a direct line
... but when they use a direct line, dragging this element, the line would follow
... so either you would take advantage of the auto routing, which would be a straight line in the first version,
or you would write your own path
... but you always get the logical connection
... in later versions you could provide some way to tell it to do routing
... there are two problems with diagrams like this
... one is the line routing
... the second is the node placement
... we're also not going to solve that, unless it gets solved in the bounds of some layout algorithm
... e.g. cameron's layout might take care of that
CL: you're not just going to point at an object, but then you to say i'm going from this point to this other point
AG: you could specify the endpoints as bounding box percentages
DS: i'm not sure that's going be satisfying
... e.g. on a diamond shape, you don't want connecting lines going to one of its sides
... so not necessarily the shortest path
... we've already thought of the idea of svg point elements
... it could act as an anchor point
... so what if we defined the anchor points of children of the element
AG: how do you associate the connectors with an object?
... i was thinking they might be a child
DS: can't be a child of two elements though
... they can be in their own block somewhere
... you can name the point you want to connect to
... the default might be to choose the shortest path between the possible anchor points on the shapes
... you could name these anchors and identify them explicitly
AG: could you have free floating svg:points?
DS: in future versions
AG: many-to-many connections?
DS: no, just one-to-one connections
CM: i wonder if you ever want navigation that is different from what the connections indicate
as far as semantics of relationships, you should be able to extract a triple from this diagram
as far as navigation goes, they don't ahve to render, might be a better way to define meaningful navigation with titles/descs
rather than using nav-next/-prev attributes
RESOLUTION: We'll consider the connector proposal
ACTION: Doug to write up the connector proposal [recorded in http://www.w3.org/2009/09/30-svg-minutes.html#action04]
Created ACTION-2681 - Write up the connector proposal [on Doug Schepers - due 2009-10-08].