OK. I'll bite...
Some features of DFDL take some time
to understand, and some are not perfectly described in the specification.
That does make it hard for somebody in your position because you only have
the specification to go on, As far as I'm concerned, you should feel free
to raise questions like this without apology.
In this case, neither Daffodil nor IBM
DFDL is violating the (intended) rules in the specification. The properties
from the imported xsd are not being used by a *component* in the main xsd.
Instead, the 'ref' attribute of the global format block in the main xsd
is referring to a named format block in the imported xsd. In this way,
the library xsd is contributing a wide-ranging list of default values into
the global format block of the main xsd.
I expect Steve or Mike will add some
details to that...
regards,
Tim Kimber, DFDL Team,
Hursley, UK
Internet: kimbert@uk.ibm.com
Tel. 01962-816742
Internal tel. 37246742
From:
"Garriss Jr.,
James P." <jgarriss@mitre.org>
To:
"dfdl-wg@ogf.org"
<dfdl-wg@ogf.org>,
Date:
25/04/2013 15:00
Subject:
[DFDL-WG] MBTK
and Daffodil - Intentioning Violating Property Scoping
Rules?
Sent by:
dfdl-wg-bounces@ogf.org
(Emotions are hard to convey in email;
please trust me when I say that I am writing this email with kindness and
friendliness!)
In section 8 it says, “The dfdl:format
annotation on the top level xs:schema declaration provides defaults for
the DFDL representation properties at every DFDL-annotatable component
contained in the schema document. They do not apply to any components in
any included or imported schema document (these may have their own defaults).”
If I understand this, it means that when
properties are defined using <dfdl:format> in one DFDL schema file,
they are out of scope for any other DFDL schema file.
So if schema A defines some properties
and includes schema B, the properties are out of scope in schema B.
Similarly, if schema A includes schema
B and schema B defines some properties, the properties are out of scope
in schema A.
Is that right? I think so, and I
have empirically confirmed this in both tools.
Ok, so you know where this going, right?
Why does the following line work?
<xsd:import namespace="http://www.ibm.com/dfdl/GeneralPurposeFormat"
schemaLocation="IBMdefined/GeneralPurposeFormat.xsd"/>
According to the spec, it shouldn’t. Yet
both tools support it.
But if you make any changes to the GeneralPurposeFormat,
it breaks. You can’t rename it. You can’t put it in a different
folder. Etc.
Here’s what I suspect: Both MBTK
and Daffodil hard-coded this as an undocumented exception to the rule.
I think you want to have your cake (properties
are out of scope) and eat it, too (except when we want them to be in scope
because repeating all the properties in every DFDL file is a pain).
If I’m wrong, just let me know. It’s
entirely possible that I don’t really understand what’s going here.
But if I’m right, then you guys should
not do this.
· If
the spec makes sense, then you should follow the spec.
· If
the spec doesn’t make sense, then you should change the spec.
· If
the spec needs an exception to the rule for this one case, then add an
exception and follow it.
To intentionally break the spec in an undocumented
fashion seems wrong.--
dfdl-wg mailing list
dfdl-wg@ogf.org
https://www.ogf.org/mailman/listinfo/dfdl-wg
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU