[DFDL-WG] Minutes of 2007-07-18 meeting

[Mike Beckerle]

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.

------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/dfdl-wg/attachments/20070718/ef4685e4/attachment.htm