Re: [odata] Topic: Schema - place and language (changed from minutes comment)

[Farrukh Najmi <farrukh@wellfleetsoftware.com>]

On 09/12/2012 05:37 AM, Stefan Drees wrote:

Hi Ralf,

Am 07.09.12 10:52, schrieb Handl, Ralf:

...Looking at our SVN repository I see mainly plural names: starting with
the SVN conventions /branches and /tags, continuing with
/trunk/fingerprints, /trunk/minutes, /trunk/proposals, /trunk/tools, so
/trunk/spec/schemas fits in nicely.

In fact the only exception is /trunk/spec, so maybe we should rename it
to /trunk/specs J

+1 In my experience a TC may have multiple specs (e.g. core, extensions, etc.)

I’d like to keep the folder tree as shallow (or fordable) as possible,
so I’d prefer /xsd over /schema/xsd (and still prefer /schemas over /xsd J).

@All: opinions?

I prefer /xsd over /schema/xsd and /schemas.

...

no problem with SVN folder names. I had more the packaging target and subsequent URL for client XMLs in mind.

I also left the minutes untouched, since /trunk/schemas nicely qualifies as a "schema subfolder" as minuted from the discussion.

I had made a proposal a while back to consider treating the TC artifacts in source control (svn) in a manner similar to a multi-module software project that uses maven to automate the various aspects of managing spec artifacts (e.g. build, package, test, release, deploy etc.).

If we were to use maven for building and managing our spec artifacts then the structure of the svn tree would be based on established maven practices for a multi-module project. Here is an example of what that could look like relative to /trunk:

./pom.xml        (the top level build configuration file that builds all sub-modules such as odata-core, checkABNF etc.)
./README.txt    (describe structure and how to build)
./specs/odata-core    (core spec)
./specs/odata-core/src
./specs/odata-core/src/main
./specs/odata-core/src/main/resources
./specs/odata-core/src/main/resources/wsdl (wsdl files)
./specs/odata-core/src/main/resources/xml (xml files)
./specs/odata-core/src/main/resources/doc (documents such as .doc, .odt but not generated types like .pdf)
./specs/odata-core/src/main/resources/xsd (xsd files)
./specs/odata-core/src/main/resources/xsl    (xsl files)
./specs/odata-core/src/main/assembly
./specs/odata-core/src/main/assembly/assembly.xml (file that describes how to assemble a zip file conforming to OASIS web site structure)
./specs/odata-core/pom.xml (build configuration file for odata-core module)
./catalog.xml (any entries for xml catalog reslver)
./specs/odata-core-bindings/catalog.xml

./tools/checkABNF (using convention to use lower-camel-case for package/directory names)
./tools/checkABNF/pom.xml (build configuration file for checkABNF module)
./tools/checkABNF/src
./tools/checkABNF/src/main (subtree for sources)
./tools/checkABNF/src/main/java
./tools/checkABNF/src/main/resources
./tools/checkABNF/src/test     (subtree for automated tests)
./tools/checkABNF/src/test/java
./tools/checkABNF/src/test/resources

./proposals/
./minutes

NOTES:

• No dependencies (e.g. apg) will be in svn as their correct version is automatically gotten by maven as a dependency from a remote repository during build
• No generated documents such as pdf will be in the svn tree as they will be generated during build
• The build process would be supported by most IDEs (eclipse, netbeans, IDEA, ...) because they all support maven
  

If there is interest I would be happy to answer questions and help if TC decides to pursue it. If not, no worries. I just want to make sure that the proposal is understood and considered.

Onto something completely different: As we do not seem to be able to come up with a normative schema for CSDL, might we enhance the situation, in adding a more capable schema language, where all scenarios might be supported/validated against, thus describing CSDL normatively? What about RELAX NG, or schematron?

Relax NG is an alternative to XSD but I thought Schematron is for a different purpose. Where XSD enforces syntactic rules on XML,  Schematron is for enforcing more higher level business rules.

I advice sticking with XSD as it has much better tool support and overall traction.

@All: opinions? Shall we investigate? What were the corner cases, that show the "unexpressible parts" of a schema attempt formulated in the W§C Schema Language?

I am curious what are the barriers to a normative schema for CSDL? Could they be overcome by using XSD + Schematron?

Thanks.

-- 
Regards,
Farrukh Najmi

Web: http://www.wellfleetsoftware.com