[API Review]: Add 'fxml.version' to System Properties (Was: FXML version number)

[Svata Dedic]

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.