Not sure if I missed a thread while I was out on vacation on why this wasn't changed, (so don't yell at me too loud. :)) but this line (3) needs to be changed from <xs:import namespace="http://www.w3.org/XML/1998/namespace"; schemaLocation="xml.xsd"/> to <xs:import namespace="http://www.w3.org/XML/1998/namespace"; schemaLocation="http://www.w3.org/2001/xml.xsd"/>
This will make validators look in the right place for xml.xsd instead of looking to http://schemas.habariproject.org/xml.xsd which doesn't exist. The w3 validator works because it does have a local copy of xml.xsd. This will allow you to validate your own xml using php with something like the following: #!/usr/bin/php <?php $xsdURI = "http://schemas.habariproject.org/Pluggable-1.2.xsd";; if ( ! $argv[1] ) { die("\nMust specify .xml file to validate.\n"); } $xmlFile = $argv[1]; if ( ! file_exists( $xmlFile ) ) { die("\nBad file specified.\n"); } $xsd = file_get_contents( $xsdURI ); $doc = new DomDocument; $doc->load( $xmlFile ); if ( $doc->schemaValidateSource( $xsd ) ) { echo "\nXML is valid.\n"; } else { echo "\nXML is *NOT* valid.\n"; } ?> -Ryan On Jun 20, 2009, at 9:52 AM, Owen Winkler wrote: > > Arthus Erea wrote: >> Please write some documentation. >> >> Please respond to criticism and admit you're not infallible. > > The Pluggable XML format does need some more written-language > documentation, even though the XSD is mostly complete. (Some guidance > from those who know on how to correct the XSD to work with non-local > validators would be helpful.) > > Until that documentation is written (which you are welcome to begin, > instead of waiting for someone else), you can find these resources > here: > > Pluggable XSD: http://schemas.habariproject.org/Pluggable-1.2.xsd > Sample XML: http://schemas.habariproject.org/pluggable-sample.xml > > If while writing the documentation, you have specific questions, > posting > them here should yield specific direct answers and input from others. > > Regarding another query posed about tying plugins explicitly to Habari > versions -- > I'm unsure that this is the best approach, in the same way that I know > that a theme's requiring a specific plugin by name is the wrong > approach. Primarily my opinion on this is based on the concept that > it's not a version of Habari that a plugin targets, but a feature that > Habari provides. > > So the question is, should Habari itself provide "features", as > included > in the pluggable xml, that plugins can then require or recommend as > needed? > > Bear in mind that major version releases of Habari should be API- > stable. > So it would be useful to include a single feature of "Habari 1.0" > when > that time comes. But for the 0.x branch, features change so often, > especially in the trunk, that simply indicating "0.7" as a requirement > may not be enough. Especially for the useful features that we > continue > to modify and add in 0.7, an 0.7 Habari checked out at the beginning > of > the branch's life would not have any of the features implied by the > requisite of "0.7". > > Owen > > > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/habari-dev -~----------~----~----~----~------~----~------~--~---
