Hi,
sorry to step in in the middle of the discussion. I was pointed to this
thread only lately, as a part of review process of
https://javafx-jira.kenai.com/browse/RT-28599
The note about XML diff / processing tools is valid; indeed even
NetBeans which processes FXML must be adapted to creatively handle
namespace with URIs matching a certain prefix.
But... consider the FXML file as a XML document. It's grammar must
correspond to the version of Javafx runtime - or at least to one of the
already released past versions. I.e., the FXML should not use an unknown
property or unknown class (more on the classpath contents concept
below). So each version of Javafx runtime library constitutes a set of
tags for classes, for class properties and events - which means a XML
schema could be eventually generated for each javafx release. And XML
schemas are usually identified by their target namespace URI and
referenced using a xml namespace prefix declared in the document.
In addition, we *need* a namespace different from the fx: namespace:
while the [default] namespace contains elements from the javafx runtime
"language", the fx: namespace contains elements from the FXML loader
"language" (references, includes, ids). As Milan has pointed out, those
languages are likely to evolve independently, but definitely have
different 'schemas' (although generated).
Consider for example a XSLT-based tool for FXML translation or
processing: it can react appropriately to XML elemnents targetting
different javafx runtimes, allowing to develop a XSLT-based
transformation which is universal. If fx:version was used, matching in
XSLT and XPaths would be unnatural to those languages instead of
matching just for QName, you need to construct a XPath expression like
/*[fx:version='8']//javafx:AnchorPane
or even more bloated syntax.
From this point of view, using XML namespace makes a lot of sense for
XML processing tools than fx:version, with an implicit rule to inherit
fx:version down the element hierarchy until a different one is found.
As for the 'classpath contents' concept: there's one unresolved issue
with either fx:version or xmlns declaration. We allow to declare the
version of javafx runtime in the fxml, but the actual usable language
(components, their properties and events) are defined by the contents of
the classpath, that possibly contain additional libraries.
Right now, a 3rd party (e.g.) ChoiceBox component element will use a
QName from javafx namespace as if that component was a part of core
javafx runtime library, which does not as the "right XML way" (but it's
the way how FXML works at the moment).
While we now define a versioning mechanism for our own library (javafx
runtime), we do not define anything that can be useful by 3rd party
vendors to version their component state persisted in FXML - which is a
pity.
On 07/09/2013 11:57 AM, Werner Lehmann wrote:
Hi,
I don't particularly prefer one way or another but the first thing which
came to my mind is to use a processing instruction. Especially because
it can be "used by tools somehow". XML itself shows this:
<?xml version="1.0" encoding="UTF-8"?>
Using a processing instruction could be used if ever just one version
applies to the entire FXML source. While processing instructions apply
in textual order, FXML elements nest, so multiple PIs would bring a
total havoc to the processing tools.
My preference would be:
1/ versioned xml namespace. Each QName then represents an entity as
specified by whatever javafx release. Conforms to usual
backwards-compatible XML format evolution rules
2/ processing instruction. Out of band for most tools. I didn't think
about this mechanism before - sorry, Milan.
...
99/ special attribute. Provides no processing benefit, while complicates
both matching and validation, i.e. non-standard way to suggest
appropriate schema.
my 2 cents,
-Svata
My 2c.
Werner
On 09.07.2013 09:06, Milan Kubec wrote:
This information can be then used by tools somehow.
