On Thu, 7 Apr 2005 aaron@...749... wrote:
Perhaps I will have to learn to read C++ sooner than I had wanted to. :) Is there a DTD?
Well, there isn't. This is partially for two reasons:
1) I'm lazy 2) I don't know how to (see 1)
If you'd write one, I'd maintain it as I make changes to the format (should be pretty stable at this point though). I think that I've heard XSchema is better, but I don't know enough about them.
As far as passing to scripts, how do you want it? We've discussed it in the past, but it never got implemented. I was thinking something like "./myscript --name=value"
That is exactly what I would expect.
Okay, I'll get on to adding that.
but as the most active script developer, how ever you'd like would be germane in my eyes.
A very sad commentary on the state of the art, don't you think? :)
Yes, but I don't blame people. It is still a black art without enough functionality to do really cool things. That is starting to change though.
--Ted
ted@...11... wrote:
On Thu, 7 Apr 2005 aaron@...749... wrote:
Perhaps I will have to learn to read C++ sooner than I had wanted to. :) Is there a DTD?
Well, there isn't. This is partially for two reasons:
- I'm lazy
- I don't know how to (see 1)
If you'd write one, I'd maintain it as I make changes to the format (should be pretty stable at this point though). I think that I've heard XSchema is better, but I don't know enough about them.
Well. I don't know how to write a dtd either, yet. But I should learn. I get the feeling that this would be a perfect wiki project. Since that would let people who know dtd and people who know the inx format tweak the document. But I'm not sure a wiki would handle that sort of character data. Perhaps it can find a home in CVS. If I should be XSchema let me know. This is what came up with from the *.inx files I have and no real knowledge of DTD:
<!ELEMENT inkscape-extension (name, id, dependency*, param*,(input|output|effect),(script|plugin))> <!ELEMENT input (extension, mimetype, filetype, filetypetooltip, output_extension?)> <!ELEMENT output (extension, mimetype, filetype, filetypetooltip, dataloss?)> <!ELEMENT effect (object-type)> <!ELEMENT script (command, helper_extension*, check*)> <!ELEMENT plugin (name)> <!ELEMENT name (#PCDATA)> <!ELEMENT id (#PCDATA)> <!ELEMENT dependency (#PCDATA)> <!ELEMENT param (#PCDATA)> <!ELEMENT extension (#PCDATA)> <!ELEMENT mimetype (#PCDATA)> <!ELEMENT filetype (#PCDATA)> <!ELEMENT filetooltip (#PCDATA)> <!ELEMENT object-type (#PCDATA)> <!ELEMENT command (#PCDATA)> <!ELEMENT check (#PCDATA)> <!ELEMENT dataloss (#PCDATA)> <!ELEMENT helper_extension (#PCDATA)> <!ELEMENT output_extension (#PCDATA)>
<!ATTLIST check reldir (absolute|path|extensions|plugins) #REQUIRED> <!ATTLIST command reldir (absolute|path|extensions|plugins) #REQUIRED> <!ATTLIST dependency type (executable|extension) #REQUIRED> <!ATTLIST dependency location (absolute|path|extensions|plugins) #IMPLIED> <!ATTLIST dependency description CDATA #IMPLIED> <!ATTLIST param name CDATA #REQUIRED> <!ATTLIST param type (float|int) #REQUIRED>
Just looking it seems to me that some elements might be missing (like input-extension). I also wonder if it would be worth the trouble to be consistent in the formatting of element names (ie replace all the _s with -s). But maybe there is a reason for the way it is.
"./myscript --name=value"
That is exactly what I would expect.
Okay, I'll get on to adding that.
Thank you. Once I can input parameters in a gui and then have those parameters passed to my scripts, I will have every feature I want. (Well except for access to those nifty curve fitting functions in bezier-utils.cpp, but that will have to wait for internal scripting.)
It is still a black art without enough functionality to do really cool things. That is starting to change though.
I think documentation will help. That is why I'm putting forth this meager attempt to learn about extensions and write up some notes. I know that once extension are made more public people will start writing extensions that run circles around anything I could ever dream of programming.
Thanks Aaron Spike
On Thu, Apr 07, 2005 at 09:34:55PM -0500, aaron@...749... wrote:
ted@...11... wrote:
On Thu, 7 Apr 2005 aaron@...749... wrote:
Perhaps I will have to learn to read C++ sooner than I had wanted to. :) Is there a DTD?
Well, there isn't. This is partially for two reasons:
- I'm lazy
- I don't know how to (see 1)
If you'd write one, I'd maintain it as I make changes to the format (should be pretty stable at this point though). I think that I've heard XSchema is better, but I don't know enough about them.
Well. I don't know how to write a dtd either, yet. But I should learn. I get the feeling that this would be a perfect wiki project. Since that would let people who know dtd and people who know the inx format tweak the document. But I'm not sure a wiki would handle that sort of character data. Perhaps it can find a home in CVS. If I should be XSchema let me know. This is what came up with from the *.inx files I have and no real knowledge of DTD:
Yes, go with XSchemas, don't bother with DTD's. They're supposedly deprecated, although a lot of people still use them. There's some docs on XML Schemas at xml.com.
IMHO, XSchemas aren't really that much better or easier than DTD's, but they're implemented as XML documents, so at least you're using a consistent syntax.
<!ELEMENT inkscape-extension (name, id, dependency*, param*,(input|output|effect),(script|plugin))>
<!ELEMENT input (extension, mimetype, filetype, filetypetooltip, output_extension?)>
<!ELEMENT output (extension, mimetype, filetype, filetypetooltip, dataloss?)>
<!ELEMENT effect (object-type)>
<!ELEMENT script (command, helper_extension*, check*)>
<!ELEMENT plugin (name)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT id (#PCDATA)>
<!ELEMENT dependency (#PCDATA)>
<!ELEMENT param (#PCDATA)>
<!ELEMENT extension (#PCDATA)>
<!ELEMENT mimetype (#PCDATA)>
<!ELEMENT filetype (#PCDATA)>
<!ELEMENT filetooltip (#PCDATA)>
<!ELEMENT object-type (#PCDATA)>
<!ELEMENT command (#PCDATA)>
<!ELEMENT check (#PCDATA)>
<!ELEMENT dataloss (#PCDATA)>
<!ELEMENT helper_extension (#PCDATA)>
<!ELEMENT output_extension (#PCDATA)>
<!ATTLIST check reldir (absolute|path|extensions|plugins) #REQUIRED>
<!ATTLIST command reldir (absolute|path|extensions|plugins) #REQUIRED>
<!ATTLIST dependency type (executable|extension) #REQUIRED>
<!ATTLIST dependency location (absolute|path|extensions|plugins) #IMPLIED>
<!ATTLIST dependency description CDATA #IMPLIED>
<!ATTLIST param name CDATA #REQUIRED>
<!ATTLIST param type (float|int) #REQUIRED>
Just looking it seems to me that some elements might be missing (like input-extension). I also wonder if it would be worth the trouble to be consistent in the formatting of element names (ie replace all the _s with -s). But maybe there is a reason for the way it is.
Yeah, try to remain consistent. You've actually got three cases:
* dashed-words * underscored_words * joinedwords
I'd suggest going with just one style for all elements if you can.
Bryce
Bryce Harrington wrote:
IMHO, XSchemas aren't really that much better or easier than DTD's, but they're implemented as XML documents, so at least you're using a consistent syntax.
Well...
schemas are a lot nicer than DTDs, since there's a lot they can do that DTDs can't. One of them is mix stuff in the manner that SVG can be intermixed with XHTML or XForms or more.
And a Schema aware editor can do some nice things.
On Fri, Apr 08, 2005 at 12:33:52AM -0700, Jon A. Cruz wrote:
Bryce Harrington wrote:
IMHO, XSchemas aren't really that much better or easier than DTD's, but they're implemented as XML documents, so at least you're using a consistent syntax.
Well...
schemas are a lot nicer than DTDs, since there's a lot they can do that DTDs can't. One of them is mix stuff in the manner that SVG can be intermixed with XHTML or XForms or more.
I guess, but that's not really been a needed capability in any of the XML designs I've been involved with.
And a Schema aware editor can do some nice things.
Eh.
Anyway, XSchema is the way to go, just take the hype with a grain of salt.
In particular, a thing to beware of is that once folks learn XSchema they of course want to play with all it's features. ;-) However (IMHO), the most useful XML's keep things simple and consistent. Don't put too much smarts into the schema definition, else it could get confusing for future maintainers.
Bryce
Bryce Harrington dicharò:
Anyway, XSchema is the way to go, just take the hype with a grain of salt.
In particular, a thing to beware of is that once folks learn XSchema they of course want to play with all it's features. ;-) However (IMHO), the most useful XML's keep things simple and consistent. Don't put too much smarts into the schema definition, else it could get confusing for future maintainers.
XML Schema is very complex and a better choiche could be RelaxNG, which is fully supported by libxml2 (XML Schema is currently not fully supported).
Quoting Emanuele Aina <faina.mail@...92...>:
XML Schema is very complex and a better choiche could be RelaxNG, which=20 is fully supported by libxml2 (XML Schema is currently not fully supported).
Seconded. RelaxNG is what XML Schema ought to have been.
There's a reason many standards (SVG 1.2 included) are beginning to develop with RelaxNG and only translate to XML Schema for the final version...
-mental
On Fri, 8 Apr 2005, Bryce Harrington wrote:
Yeah, try to remain consistent. You've actually got three cases:
- dashed-words
- underscored_words
- joinedwords
I'd suggest going with just one style for all elements if you can.
I thought we had talked about which one of these to use for Inkscape namespace attributes in SVG documents. Which one was it? I think it should be the same. One naming standard to rule them all.
--Ted
Quoting ted@...11...:
I thought we had talked about which one of these to use for Inkscape namespace attributes in SVG documents. Which one was it? I think it should be the same. One naming standard to rule them all.
Lower case, using dashes as a word separator.
-mental
participants (4)
-
unknown＠example.com -
Bryce Harrington -
Emanuele Aina -
Jon A. Cruz