[DFDL-WG] MBTK and Daffodil - Intentioning Violating Property Scoping Rules?

[Suman Kalia]

>>> 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 at ca.ibm.com

For info on Message broker
http://www.ibm.com/developerworks/websphere/zones/businessintegration/wmb.html





From:   "Garriss Jr., James P." <jgarriss at mitre.org>
To:     "dfdl-wg at ogf.org" <dfdl-wg at 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 at 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 at ogf.org
  https://www.ogf.org/mailman/listinfo/dfdl-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20130425/7057e5d2/attachment-0001.html>