The only reason I changed the soap one from a URN back to a URL is because of all the different namespaces we have (there's more than one might think), it was the ONLY one that wasn't in URL form, so I changed it to be consistent.
That being said, I do like the URN format better, so if people agree, we can change it. I would respectfully ask, however, that I be the one to make the change, considering I know all the deep, dark corners where they all need to change (xsd, xml, properties, a couple java files...) I can do this pretty quickly as part of https://issues.jboss.org/browse/SWITCHYARD-119. I just want them all to be consistent.
I also agree, so let 'er rip.
Well the advantage of them being proper URLs is if you can actually locate the XSD at that address, makes loading of the XSDs a lot easier in your IDE (just right click). Well... at least in In*****J Of course you can use xmlSchemaLocation, but that adds a lot more noise to the config.
Blah blah blah...
I'm OK with URNs too
The URLs never pointed to actual xsd locations. Actually, I wrote some clever (if I do say so myself) code to automagically locate XSDs based on namespaces, even when those schemas include or import other schemas - all without going out on the 'net (which is important for running on closed networks).
But the URLs could point to real locations if you set it up that way... other projects do this. This is just for ease of use with IDEs however... sure the runtime would require non-network access to them.
Okay everybody, here are the namespace changes I made on my SWITCHYARD-119 branch of core and components.
The format is:
"urn:" + [maven artifactId | example app name] + ":" + [identifier] + ":" + [version]
Where [identifier] is:
for real stuff: [package section]
for test cases: "test-" + [package section]
for example apps: "example"
I checked, and the above scheme is indeed valid URN format, according to W3C.
http://www.switchyard.org/config/model/switchyard/v1 -> urn:switchyard-config:switchyard:1.0
http://www.switchyard.org/config/model/transform/v1 -> urn:switchyard-config:transform:1.0
http://www.switchyard.org/component/bean/config/model/v1 -> urn:switchyard-component-bean:config:1.0
http://www.switchyard.org/component/soap/config/model/v1 -> urn:switchyard-component-soap:config:1.0
http://www.switchyard.org/config/model/composite/test/bean -> urn:switchyard-config:test-bean:1.0
http://www.switchyard.org/config/model/composite/test/bogus -> urn:switchyard-config:test-bogus:1.0
http://www.switchyard.org/config/model/composite/test/soap -> urn:switchyard-config:test-soap:1.0
http://www.switchyard.org/config/model/switchyard/test/java -> urn:switchyard-config:test-java:1.0
http://www.switchyard.org/config/model/switchyard/test/smooks -> urn:switchyard-config:test-smooks:1.0
http://www.switchyard.org -> urn:switchyard-transform:test-transformers:1.0
http://greeting.soap.component.switchyard.org/ -> urn:switchyard-component-soap:test-greeting:1.0
http://test.ws/ -> urn:switchyard-component-soap:test-ws:1.0
http://www.switchyard.org/example/bogus -> urn:bogus:example:1.0
http://www.switchyard.org/example/m1app -> urn:m1app:example:1.0
I hope y'all like it (or at least find it sufficient), 'cause it took a bit of work, and I don't feel like re-doing it.
This is more structured and easier to parse than what we have now, so I give it a thumbs up. The rules you listed appear reasonable at a 10,000 ft. level. I'm sure that time and additional requirements for the 0.1 release will give us plenty of reason to argue over them. For now, I say book it!
Awesome, I like the config files now .