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.
------------------------------------------------------------------------