I may be coming into this a little late, but I have concerns about using the default namespace for version identification. I feel a namespaced attribute in a namespace fixed across versions to identify the semantics would be a better choice, i.e.:
<?import javafx.scene.control.*?> <Button text="press me" xmlns:fx="http://javafx.com/fxml/1" fx:version="2.2"/> <?import javafx.scene.control.*?> <Button text="press me" xmlns:fx="http://javafx.com/fxml/1" fx:version="8.0"/> My concern is that tool automation that is sensitive to fully qualified names may have a difficult time interacting with what amounts to namespaces that can arbitrarily changed underneath them. As is stands the tools need to look at namespace-aware attributes to determine some values (such as fx:id) so simply turning off namespacing is a problematic choice already. One very problematic application would be XML diff tools, as making them match some namespaces and not others can be difficult. The entire document would become a diff then since the FQ name of the root node is different. On Fri, Jul 5, 2013 at 9:17 AM, Eric Le Ponner <eric.le.pon...@oracle.com>wrote: > Hi Milan, > > This looks good. > > Note that, since b28, Scene Builder 1.1 now generates FXML files which > include: > xmlns:fx="http://javafx.com/fxml/1" > xmlns="http://javafx.com/javafx/2.2" > > Scene Builder Next will do the same but using values from 'fxml.version' > and 'javafx.version'. > It may also use those variables to improve error report or version > management (to be defined). > > Cheers. > > Eric > > > > > From: Milan Kubec <milan.ku...@oracle.com> > > Subject: [API Review]: Add 'fxml.version' to System Properties (Was: > FXML version number) > > Date: July 1, 2013 7:01:12 AM PDT > > To: "openjfx-dev@openjdk.java.net" <openjfx-dev@openjdk.java.net> > > Reply-To: milan.ku...@oracle.com > > > > Hello, > > I propose to add 'fxml.version' property to JVM System Properties to > > store version of FXML specific version that is supported by FXML Loader. > > The property would be more specific equivalent of 'javafx.version' > > because these two versions won't advance simultaneously. > > > > Details about versioning and proposed namespaces are described in issue: > > https://javafx-jira.kenai.com/browse/RT-28599 > > > > Thanks for comments > > > > Milan > > > > > > Dne 7.6.2013 10:49, Milan Kubec napsal(a): > >> Hello, > >> I have implemented simple versioning for FXML documents in FXMLLoader, > but without support in tools it won't be very useful. I have agreed with > NetBeans and Scene Builder folks that they will include support for > versioning too. Support means that they will produce document with two XML > namespaces - one defines version of fx: prefixed elements and attributes > (xmlns:fx; it's already there, just the version is appended) and the other > of actual JavaFX API used to produce document (xmlns; default, no prefix). > The first will be checked, because wrong version can cause failure. The > latter is only informational, no strict checking of version is possible, > but tools can suggest to upgrade runtime, translate document etc. > >> > >> JavaFX API version is stored in System Properties as "javafx.version". > The open question is still where and how to store fxml version in code. I > think that we could have also property for this purpose, e.g. > "fxml.version" in System Properties. So far it's part of FXMLLoader API, > which is probably not very fortunate. What do you think? > >> > >> Issue details: https://javafx-jira.kenai.com/browse/RT-28599 > >> > >> Milan >