+1 Let's keep the XML easy to deal with. This smells a little funky to me.
Scott On 2013-07-05, at 12:59 PM, Danno Ferrin <danno.fer...@shemnon.com> wrote: > 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 >>
