What controls instantiation of the Builders are XML files like BuilderDataSource.xml <https://svn.apache.org/repos/asf/devicemap/trunk/data/device-data/src/main/resources/devicedata/BuilderDataSource.xml> but even that is not strictly mandated by W3C DDR that it has to be called that way, it is more or less implementation specific. It is "Spring-like" thus it could rather easily be replaced by a true DI mechanism on top of Spring, Guice or Apache DeltaSpike in future versions;-)
While preserving the W3C compliant implementations. In theory even adding W3C compliance to a future version of the "Parser" seems possible, it may simply have 2 clients grow together some day... Werner On Mon, Jan 5, 2015 at 6:23 PM, Werner Keil <[email protected]> wrote: > None, that's why a new W3C version could read a changed structure just > like file parsers do. > > There are standard definitions like "core Vocabulary", but that also > mainly describes what "minimal set of properties" should be present. > > On Mon, Jan 5, 2015 at 6:17 PM, Bertrand Delacretaz < > [email protected]> wrote: > >> On Mon, Jan 5, 2015 at 6:10 PM, Werner Keil <[email protected]> >> wrote: >> > ...If in a year or more the structure may so drastically change, that >> some or >> > all files became incompatible with the W3C standard, none of us can >> tell... >> >> What are the requirements on our device data files to allow you to >> produce a W3C DDR compatible client? >> >> My understanding is that W3C DDR is an API spec, so I'm not sure what >> it has to do with how the data is stored. >> >> -Bertrand >> > >
