DFDL WG teleconference 2007-07-18
Attendees: Mike Beckerle, Geoff Judd, Simon Parker
We reviewed Simon's comments on Draft v019. We got through only a few of
course.
sp 15 - we recommend globally that the property name "repType" be changed
to "representation"
sp 18, 19 - Original assertion annotation syntax was based on schematron.
We recommend departing from the schematron precedent and making the
assertion syntax like so:
<dfdl:assert timing="before/after" message="message text">element value is
the predicate expression</dfdl:assert>
or you can use test="expression string" if the test is simple enough.
<dfdl:discriminator ..../>
i.e., use an annotation element name to distinguish discriminators from
other assertions instead of a discriminator="true" attribute.
Simon observed that when using schematron, schematron's choices for
assertions seem to be quite awkward to use, requiring clumsy quoting and
such whenever the test expression itself contains string literals. We
already have the precedent that for property bindings we can put
expressions as the values of annotation elements by way of the optional
property binding element syntax :
<dfdl:property name="propertyName">....property value expression
...</dfdl:property>
syntax. Making assertions consistent with this seems better than the
schematron way.
Note: Simon also suggested a <dfdl:require .../> annotation - will post to
wiki example. The purpose of this seems to be to specify constant data
(aka "markup" to some people) that is found in the data syntax, but is not
part of the logical model. MikeB suggested we already have hidden elements
to do this, but couldn't point to the example in the draft spec. We'll
debate on the wiki.
sp23 - we recommend removing the constraint saying the result must be a
single node. Note that where the return result of an expression is
constrained, we need to be explicit about it. There will be many contexts
where an expression must return a single node value of a specific type,
and we need to be clear about those cases.
sp24 - we should revisit the constraints on the XPath expressions we
allow. The problem here is that we don't need a full XPath 2.0 language
expressive power, and since an XPath 2.0 implementation is quite
burdensome for implementors, we'd like to make the DFDL spec not simply
subsume XPath 2.0, but be easier to implement than that. This is a case
where just being consistent with existing standards is probably not the
way to go. We can say that we want our language to be consistent with
XPath 2.0, but a subset is very reasonable for DFDL. MikeB's example is
the flattner, the XPath "**" path component. We simply don't need this.
Recommend: we need rationale in the spec here to motivate why it's not
just XPath 2.0 in its entirety, and we need to be very precise about the
definition of the subset.
------------------------------------------------------------------------
