Is there an SVG Charter / Fprward Work Program?


Thanks for the response on the earlier post. It raises, for me, a broader 
issue. Is there a publicly available Charter / Forward Work Program for the 
SVG work? As you may be aware the XSL Working Group recently published a 
Charter which outlines their work program until Spring 2002.

It would be really useful for those of us who have an interest in SVG to have 
a similar strategic view of where those who are directly involved in 
developing SVG see the next steps in its development.

It may surprise some on the list that the XSL Group has published its forward 
work program before the XSL Recommendation has been finalised (although, of 
course, the related XSLT and XPath Recommendations were released in November 

If the Charter is publicly available I would be very interested to see the 
URL. If it is there and I have stupidly missed it then I apologise for asking 
such a basic question. But knowing the strategic forward view of SVG would be 
of great interest to me. If it is not yet available could you or Chris give 
an indication of when it might make an appearance?

Thanks in advance


Andrew Watt

In a message dated 08/09/00 18:32:45 GMT Daylight Time, jferraio@Adobe.COM 

> The SVG working group discussed having SVG support the 'z-index' property 
>  from CSS and decided against it for SVG 1.0, partly to avoid adding that 
>  extra bit of implementation complexity. Personally, I still agonize over 
>  whether 'z-index' should have been put into SVG 1.0.
>  Definitely, the W3C should consider 'z-index' for future versions of SVG.
>  Jon Ferraiolo
>  SVG Editor
>  Adobe Systems Incorporated
>  At 04:02 AM 9/8/00 -0400, wrote:
>  >In a message dated 07/09/00 23:07:25 GMT Daylight Time,
>  > writes:
>  >
>  > > Are there any plans to add alternative rendering order schemes?
>  > >  Currently, SVG documents are always rendered using the painter's 
> algorithm
>  > >  only.  To change the order in which objects are rendered, it is 
> necessary
>  > >  to rearrange the objects within the document itself, a potentially 
> costly
>  > >  and time-consuming process.
>  > >  S.
>  > >
>  >
>  >Steve,
>  >
>  >I guess it partly depends on what you mean by "costly" and 
>  >But, in principle, XSLT would allow you to reorder elements/objects within
>  >SVG source without huge difficulty.
>  >
>  >How costly or time consuming the use of XSLT would be would depend partly 
> on
>  >the complexity of the SVG source document, available XSLT skills and 
> whether
>  >there was any pattern of reordering required (i.e. could you reuse XSLT
>  >template stylesheets).
>  >
>  >Is there some technical reason why XSLT wouldn't meet your present needs?
>  >
>  >Andrew Watt

Received on Friday, 8 September 2000 15:33:58 UTC