Proposed changes to source code structure

30 views
Skip to first unread message

dneimke

unread,
Jan 29, 2011, 12:28:26 AM1/29/11
to blogml-...@googlegroups.com
Presently, the source code for BlogML is held on CodePlex.  The structure of the source code is quite complex as it has to account for:
  1. All versions of the BlogML XML Schema Definition
  2. Tools that support the XML Schema - e.g. BlogML Schema Validation Tools
  3. Blog Engine specific implementations 
We should simplify the source control structure in order to make it easier to understand, and therefore simpler to manage and to contribute to.  

To do this, I am proposing that we split the source into the following 2, separate projects:
  1. BlogML - a project for maintaining the XML schema for BlogML.  In terms of source code, this project would contain only the artifacts that are required to describe and publish the BlogML format.  This would essentially boil down to an XSD schema definition and supporting documentation.
  2. BlogMLContrib - a project for maintaining a library of supporting tools and accessories that surround the BlogML format.  This would include specific core applications such as validation tools, base classes for working with the BlogML format and other useful tools.  
Please discuss any thoughts that you might have about this proposed change.

Paul Stovell

unread,
Jan 29, 2011, 12:50:23 AM1/29/11
to blogml-...@googlegroups.com
I think splitting the standard from the sample tooling is an important change, and would help to combat the perception that BlogML is "just a .NET thing". I think it would be a good idea to switch to Google Code from Codeplex for the same reason. 

For an example of the perception I mean, see here:


Paul

dneimke

unread,
Jan 29, 2011, 12:56:03 AM1/29/11
to blogml-...@googlegroups.com
I agree about the perception thing Paul.  At the moment, you would easily think (from looking through source control) that BlogML was a .NET thing.

Also, I believe that, by effectively having the format and the tooling so close together, it makes it too tempting to change the tooling code without reflecting those changes through an "official" schema format change.

I also agree re. switching to Google Code.
Reply all
Reply to author
Forward
0 new messages