MBTK and Daffodil - Intentioning Violating Property Scoping Rules?
(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.
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
I think what you’re saying is that I’m failing to take into account this part of the schema: <xsd:annotation> <xsd:appinfo source="http://www.ogf.org/dfdl/"> <dfdl:format ref="GeneralPurposeFormat" /> </xsd:appinfo> </xsd:annotation> This avoids the out of scoping issue by providing a reference to the named <dfdl:format> in the GPF file: <dfdl:defineFormat name="GeneralPurposeFormat"> <dfdl:format alignment="1" alignmentUnits="bytes" binaryBooleanFalseRep="0" binaryBooleanTrueRep="1" … I rewrote some of the schemas to confirm that this works. Obviously this is my all mistake, so everything I’ve said below is wrong. I apologize! From: Tim Kimber [mailto:KIMBERT@uk.ibm.com] Sent: Thursday, April 25, 2013 10:20 AM To: Garriss Jr., James P. Cc: dfdl-wg@ogf.org Subject: Re: [DFDL-WG] MBTK and Daffodil - Intentioning Violating Property Scoping Rules? 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<mailto:kimbert@uk.ibm.com> Tel. 01962-816742 Internal tel. 37246742 From: "Garriss Jr., James P." <jgarriss@mitre.org<mailto:jgarriss@mitre.org>> To: "dfdl-wg@ogf.org<mailto:dfdl-wg@ogf.org>" <dfdl-wg@ogf.org<mailto: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<mailto: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<mailto: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
Here’s what I suspect: Both MBTK and Daffodil hard-coded this as an undocumented exception to the rule. Garriss - There is no special case or undocumented exception .. It is implemented as per the spec.
Your question - How the general purpose format becomes visible to the artifacts in the file .. Note we have default format defined ( hilited in bold) which references the general purpose format ; as a results any attribute defined in global general purpose format is available to the default format and hence to all artifacts in the current file.. This is the consistent approach and pattern used in our implementation.. <?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:dfdl="http://www.ogf.org/dfdl/dfdl-1.0/" xmlns:fmt="http://www.ibm.com/dfdl/GeneralPurposeFormat" xmlns:ibmSchExtn="http://www.ibm.com/schema/extensions" xmlns:xsd= "http://www.w3.org/2001/XMLSchema"> <xsd:import namespace=" http://www.ibm.com/dfdl/GeneralPurposeFormat" schemaLocation= "IBMdefined/GeneralPurposeFormat.xsd" /> <xsd:annotation> <xsd:appinfo source="http://www.ogf.org/dfdl/"> <dfdl:format ref="fmt:GeneralPurposeFormat" /> </xsd:appinfo> </xsd:annotation> </xsd:schema> Suman Kalia IBM Canada Lab WMB Toolkit Architect and Development Lead Tel: 905-413-3923 T/L 313-3923 Email: kalia@ca.ibm.com For info on Message broker http://www.ibm.com/developerworks/websphere/zones/businessintegration/wmb.ht... From: "Garriss Jr., James P." <jgarriss@mitre.org> To: "dfdl-wg@ogf.org" <dfdl-wg@ogf.org>, Date: 04/25/2013 10:20 AM 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
participants (3)
-
Garriss Jr., James P. -
Suman Kalia -
Tim Kimber