The biggest change has been with project structure and refactoring. There is now a KnitML Core project which houses functionality common to multiple projects. The KnitML Validation project concentrates on semantic validation (and light transformation which adds information requested by the initial XML file).
The newest project is the Pattern Renderer, based on Core and the basic parsing architecture already developed in Validation. I also have done a ton of repackaging after studying the project structure in depth with a slick little tool called JDepend. The most important changes eliminate cyclic package dependencies. Any software which aims to be modular needs to be free of such dependencies, so it was good to know what was going on.
I have also contacted the Oasis-Open group to see if they are interested in shepherding KnitML as a standard. More than likely they will simply not respond after having a good laugh. If that happens, I think it will be extremely unfortunate, as knitters worldwide are too often underestimated. I will keep my fingers crossed.
Anyways, almost all of the interesting action is happening in Subversion on SourceForge. Go and take a look!
[ 4 comments ] ( 88 views ) | [ 0 trackbacks ] | permalink
Our KnitML SourceForge project was approved. I've uploaded the most recent copy of my Eclipse workspace to Subversion. If you don't have (and don't want to use) Eclipse, I will be working to get an Ant build script. In the mean time, it should be relatively easy to build. Just compile everything in src/main/java against a classpath of every JAR in the lib directory. You will need at least Java 1.5. Check everything out at http://www.sourceforge.net/projects/knitml.
I've moved all functionality related to the semantic validator to a validation subpackage, so the base package is now com.knitml.validation. As other modules come to life, their package structure can now be cleanly based off of com.knitml with no worry about namespace clashes with anything in the validator.
I'm now wondering if I need to have a separate pass for validation and rendering. There are just so many options for dealing with both, it might make sense to put all inferences that the validator can make into the XML structure once it's done validating, which would decouple the renderer from the validator. The validator for instance should add an attribute to the XML element <turn> called "stitches-left" when an "inform-unworked-stitches" for that <turn> element is set to true. This might lead to confusion, however, at the state of the XML at any given time. Can an unvalidated KnitML document be rendered? I imagine we could have two different XSDs, one being slightly deviant from the other, but I fear this would simply be too confusing.
Another thing I need to figure out is how to express composite rows, i.e. "Rows 1,3,5,6,8,9: Knit". It would be too difficult for the engine to infer this; it would have to be explicit in the KnitML if it were to be rendered that way. I imagine an xsd:list element would do the trick, but I would have to make sure that if rows were specified this way, all rows would have to be explicit until a "reset-row-count" is issued. Shouldn't be too hard.
[ add comment ] ( 3 views ) | [ 0 trackbacks ] | permalink
I've added an About KnitML link to the sidebar to give an overview of the project and its goals. I also restructured the links a bit to make it a bit clearer as to what they do. Let me know what you think.
Also, I'm accepting candidate knitting patterns for KnitML transformation. They have to already be free, and if you need to get the designer's permission to publish it, please get that first before we publish it here. If you want to just hand me the pattern, that's fine. If you want to try to convert it to KnitML yourself, that's even better! Just document where you need to expand the Schema and we'll work those changes into the main spec.
[ add comment ] ( 2 views ) | [ 0 trackbacks ] | permalink
The basic sock pattern passes through the engine with no validation errors! I've updated the code, the pattern, and the schemas on the sidebar, so take a look at the newest. The schema and the pattern haven't changed a whole lot, though there are some minor tweaks to the pattern. It doesn't render anything yet, but pffft! Child's play. :)
I think I'm going to concentrate on getting all of this into SourceForge next.
[ add comment ] ( 3 views ) | [ 0 trackbacks ] | permalink
I am absolutely amazed that the KnitML group on Ravelry has grown from just me to 51 members in 4 days! It's so nice to meet all of you, and I look forward to discussing and sharing code and ideas with everyone.
Ravelry users: you've read what's below already.
Hopefully by the this time you've had a chance to see how I've marked up a basic sock pattern. So I want to know where we should go from here. I was originally planning on getting the engine and a basic renderer complete for trying to figure out where to go next, but I've realized that this is really an artificial line in the sand. You're all here, and some of you are very excited about getting involved.
I think it would be great if we each started writing programs and transformations that interested us the most (in whatever language we are most comfortable with). Everything developed would rally around the spec, allowing us to iteratively refine it as we go. We won't really know if there are issues with it until we dive in.
I've shared my ideas already. I want to hear yours. Don't worry if something has already been said. Say it again if it interests you. We'll collect common ideas together later. For now, just brainstorm!
[ add comment ] ( 6 views ) | [ 0 trackbacks ] | permalink
Archives
