[DFDL-WG] Expressing semantics of DFDL: is complexType syntax enough to capture scoping behavior impact?

Wed Nov 5 09:47:23 CST 2008

In the DFDL spec., the problem exists of how to express the behavior of a
construct in the situation where there are properties in scope surrounding 
the construct. 

Because of the large degree of simplification that the latest scoping rule
change implies, (this being that properties are local unless placed on
complexType forms),
I believe this kind of syntax can be used in the spec. to make clear the
implications of scope:

<complexType dfdl:lengthKind="implicit"
             dfdl:representation="text" > // these are in the scope
....

<sequence dfdl:separator="," dfdl:terminator=";" 
          dfdl:lengthKind="delimited">   // these are local
    <element name="f1" type="string" /> 
    <element name="f2" type="string" /> 
</sequence> 

....
</complexType>

Notice my use of an enclosing complexType and ellipsis in order to achieve
the notion that certain property bindings surround the example in the scope.

There are some implicit things going on here. The "...." ellipsis doesn't
mean "anything", it means "anything except something that changes the scoped
properties" because that's the whole point of the illustration here after
all!

It was previously proposed by Sandy Gao, that we adopt the XSD Schema
Components, and the notations they use in the specs that use them, as a
means to specify DFDL semantics. The schema components have a model, and
specs which discuss them must have a textual syntax for discussing instances
of the model. They give the semantics of XSD in terms of translation of the
XSD syntax into the model, then the semantics in terms of the model
instances. This syntax for the schema components model is specifically not
XSD. A key reason XSD needed this two-level approach is that they have the
job of explaining XSD Schema syntax, namespaces, import/include/redefine
(and now override in 1.1). By adoping the schema components model they can
dispense with all issues about how multiple schema documents are assembled
into a single "schema" consisting of a collection of schema components. Then
they can get to the task of explaining what the collection of schema
components means. 

Now, to me it is quite problematic to express DFDL semantics in terms of an
entire intermediate language we create just because XSD did it this way. We
don't need to explain the way namespaces and multi-file schema composition
work. XSD has already done this. We want DFDL's spec not to reproduce that
work, but to just assume that is understood from the XSD work, and focus on
what is unique about DFDL.  I would prefer to appeal to reason here, express
the semantics in terms of familiar DFDL syntactic elements. 

I believe there is one tricky issue: element reference, and group reference.
This is the issue of the properties being combined, so that annotions on the
reference override annotations on the top level of the declaration.   I
believe we can describe this sufficiently without adopting a whole two-layer
model. It's not worth it just for this. 

I lied. There is a second tricky issue: recursive types - however, we've
ruled these out of DFDL v1.0, so we're ok here.

Comments?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/dfdl-wg/attachments/20081105/10f23e44/attachment-0001.html 