On Sep 29, 2006, at 4:41 PM, MenTaLguY wrote: Sounds like time for "target profiles" or some such. There are a few things that can be leveraged: UI simplification, tool restrictions, "out of target" warnings, validation, etc. One feature to help targeting specific profiles would be to add an "out of profile" warning to nodes in the Object tree. Among other things this could aid in "correcting" a file for a target profile. This might be a good first step as it is far simpler than trying to automatically correct SVG and also simpler than dynamic munging of the UI and tools. An additional UI change that can come in would be a target preview. This work could be leveraged for animation later on down the road, as that would also benefit from a dual edit/preview split. One easy enhancement for the "target preview" UI could be simple lcms display profiles. Then a given SVG Tiny device preview could have things like 12-bit or 16-bit color simulated by the use of CMS. Helping artists avoid "what the heck happened to my gradient" surprises could be quite useful. And as we move into implementing things, a little implementation tool might be Schematron. First of all, the schematroll is cute. :-) However, it does allow for structure validation through simple XPath "test" statements, and for various reasons we have XPath going into our codebase already. One then could use simple rules both for validating SVG in use and for turning on and off parts of the UI and tools.

On Oct 2, 2006, at 3:05 PM, Jon Phillips wrote: Ahh... good. Someone took the bait. This is the Schematrol http://xml.ascc.net/resource/schematron/bilby.jpg And Schematron: http://en.wikipedia.org/wiki/Schematron It's a very interesting approach that sets out a simple method to apply XPath expressions as assertions on document structure.

On Mon, Oct 02, 2006 at 03:05:20PM -0700, Jon Phillips wrote: Well, we'd need to have a test-case for each feature in the spec. Does the W3C testsuite cover SVG Tiny fully enough? Bryce

An idea that I had a long time ago (noting the copyright statement, it was in 2004) is contained in svg-profile.h. The idea was that every verb could contain an Inkscape::SvgProfile object. Then you could adjust which verbs were visible (active) based on the SVG profile. The header file basically implements a fancy bitmask that can grow easily. The idea was also to make everything in a way that could be built into the static verb arrays also. Looking through the code today, there is a little bit to be desired, but I think it works. I don't believe it's ever been checked in in a state where it is linked into the build. This doesn't solve many of the SVG feature analysis issues, but it does solve some of the UI issues in 'limiting' Inkscape features so that you don't create invalid SVG. --Ted

On Oct 5, 2006, at 9:55 PM, Ted Gould wrote: I think we might want to shift things around the other way. That is, I think we should consider verbs to be lower-level atomic items that just do their job but don't know about the higher-level concept of profile grouping. Then above the verb level we could have the profile manager and profile instances. Each of these could contain the lists of verbs applicable (or a list of those blocked). I think it's important to approach it this way for a few reasons. The main one is that then there is no profile info hardcoded in the verbs themselves, and the profiles can just be loaded from files at runtime. Among other things this would allow end users to craft custom profiles to target individual phones, etc. So instead of verbs holding profile info, there would be a set of profiles that have a list of verbs to block or allow, and something else to apply the filtering by profile.

On Fri, 2006-10-06 at 10:40 -0700, Jon A. Cruz wrote: Another very important reason, to my mind, is that it would allow us to do it in terms of a general approach of setting up constraints to which verbs can be shown/active, among which constraints would be "is this verb meaningful for the current profile?" -mental