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