Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#351 Need to implement Schematron rules for attribute values

GREEN
closed-accepted
Martin Holmes
Other (8)
5
2013-06-11
2012-03-26
Martin Holmes
No

This previous bug:

https://sourceforge.net/tracker/?func=detail&atid=644062&aid=3455686&group_id=106328

divided itself into two tasks, one of which was completed, and the bug was closed. The remaining task was suggested by Lou:

"all valdescs need to be examined carefully to see whether they can be
re-expressed in schematron"

I'm happy to do this, but first I'd like someone who's done this before to give me a quick tour of how Schematron fits into the build system, and how to write tests for it. I'd suggest having a short session on this at the ftf in Michigan, so that several of us can learn how to do it.

Discussion

1 2 > >> (Page 1 of 2)
  • James Cummings
    James Cummings
    2012-04-15

    Sebastian agrees this is a good idea. But in addition we need to create a better way to write tests for things which we know will fail. to be discussed.

     
  • wrt James' comment, the setting up of tests to fail is now catered for. Whatever is in Test/detest.odd and its companion Test/detest.xml is exempt from normal checks. Its allowed to fail, and then the log of errors is compared against a known log.

     
  • James Cummings
    James Cummings
    2012-09-19

    Council suggests producing a list of candidate attribute values.

     
  • James Cummings
    James Cummings
    2012-09-19

    • milestone: 871209 --> GREEN
     
  • James Cummings
    James Cummings
    2012-09-22

    • status: open --> open-accepted
     
  • Martin Holmes
    Martin Holmes
    2012-10-07

    Trying to narrow this down a bit: I think we're primarily interested in attributes which:

    1. Have datatypes which are not constrained tightly through normal schema rules, so:
    data.code
    data.enumerated
    data.language (hard to constrain, though, as the IANA language list will change)
    data.pattern (very hard to constrain -- can you constrain a regex expression using regex?)
    data.text

     
  • Martin Holmes
    Martin Holmes
    2012-10-07

    Previous one got submitted before I finished. Another attempt:

    I think we're primarily interested in
    attributes which:

    1. Have datatypes which are not constrained tightly through normal schema
    rules, so:
    data.code
    data.enumerated
    data.language (hard to constrain, though, as the IANA language list will change)
    data.pattern (very hard to constrain -- can you constrain a regex expression using regex?)
    data.text

    2. Have a <valDesc> which explains some aspect of usage which is expressible in text but not in e.g. RNG.

    Is this the correct subset of attributes to start with?

     
  • I have removed <valDesc>s which simply repeat the data type of positive integer; that removes 10 or so from the list....

     
  • I also removed a slew of them which just repeat the datatype (ie "A URI")

     
  • Martin Holmes
    Martin Holmes
    2013-02-01

    I've gone through all remaining attributes which have a valDesc but no constraints, and found only a couple of candidates for constraints. I've created a constraint for one (<variantEncoding> attributes @method and @location). The remaining ones are attributes whose datatype is data.count, but for which the value zero would probably be inappropriate (@cols and @rows, for instance). Waiting for feedback from Council on whether zero values should be allowed. Once those are dealt with, this ticket can be closed, I think.

     
1 2 > >> (Page 1 of 2)