The content model of <constraintSpec> is currently <rng:zeroOrMore> <rng:choice> <rng:ref name="model.glossLike"/> <rng:ref name="model.descLike"/> </rng:choice> </rng:zeroOrMore> <rng:optional> </rng:optional> or, in pure ODD, <alternate minOccurs="0" maxOccurs="unbounded"> <classRef key="model.glossLike"/> <classRef key="model.descLike"/> </alternate> <elementRef key="constraint" minOccurs="0"/> The fact that this gives rise to an invalid DTD content model (there needs to be a <rng:group> or <sequence> round te whole shebang) isn't really my question though. This is my question: What on earth is the point of a <constraintSpec> that doesn't contain a <constraint>? Or if the idea was to permit just documentation (but not a specification) for one, why isn't the model just <rng:zeroOrMore> <rng:choice> <rng:ref name="model.glossLike"/> <rng:ref name="model.descLike"/> <rng:ref name="constraint"/> </rng:choice> </rng:zeroOrMore> ? I think this is a corrigible error, and the <rng:optional>ity of <constraint> should be removed.
Careless cut'n paste made my last message more incomprehensible than necessary. Apologies for that: it should have started like this
The content model of <constraintSpec> is currently
<rng:zeroOrMore> <rng:choice> <rng:ref name="model.glossLike"/> <rng:ref name="model.descLike"/> </rng:choice> </rng:zeroOrMore> <rng:optional> <rng:ref name="constraint"/> </rng:optional>
or, in pure ODD,
<alternate minOccurs="0" maxOccurs="unbounded"> <classRef key="model.glossLike"/> <classRef key="model.descLike"/> </alternate> <elementRef key="constraint" minOccurs="0"/>
The fact that this gives rise to an invalid DTD content model (there needs to be a <rng:group> or <sequence> round te whole shebang) isn't really my question though. This is my question:
What on earth is the point of a <constraintSpec> that doesn't contain a <constraint>? Or if the idea was to permit just documentation (but not a specification) for one, why isn't the model just
<rng:zeroOrMore> <rng:choice> <rng:ref name="model.glossLike"/> <rng:ref name="model.descLike"/> <rng:ref name="constraint"/> </rng:choice> </rng:zeroOrMore>
? I think this is a corrigible error, and the <rng:optional>ity of <constraint> should be removed.
Agreed. Seems mad. The only thing I can imagine is that this was originally designed before it was clear that ISO Schematron was a viable language for expressing constraints in such as way that they could be processed through to a schema and acted on by a validator, and therefore the original constraints were expressed only in prose as a sort of placeholder for future work. Cheers, Martin On 15-08-29 05:50 AM, Lou Burnard wrote:
The content model of <constraintSpec> is currently
<rng:zeroOrMore> <rng:choice> <rng:ref name="model.glossLike"/> <rng:ref name="model.descLike"/> </rng:choice> </rng:zeroOrMore> <rng:optional> </rng:optional>
or, in pure ODD,
<alternate minOccurs="0" maxOccurs="unbounded"> <classRef key="model.glossLike"/> <classRef key="model.descLike"/> </alternate> <elementRef key="constraint" minOccurs="0"/>
The fact that this gives rise to an invalid DTD content model (there needs to be a <rng:group> or <sequence> round te whole shebang) isn't really my question though. This is my question:
What on earth is the point of a <constraintSpec> that doesn't contain a <constraint>? Or if the idea was to permit just documentation (but not a specification) for one, why isn't the model just
<rng:zeroOrMore> <rng:choice> <rng:ref name="model.glossLike"/> <rng:ref name="model.descLike"/> <rng:ref name="constraint"/> </rng:choice> </rng:zeroOrMore>
? I think this is a corrigible error, and the <rng:optional>ity of <constraint> should be removed.
Hey, Martin. Nice of you to develop an argument for why we might have done that, but I'm not buying. <constraint> should be a required child of <constraintSpec>. If you really need a placeholder while you work on the formal constraint, you can leave it (the <constraint>) empty. (Its content model is ANY.) P.S. (The real question, which I personally do NOT want to get into yet, is whether or not <constraint> should be repeatable in order to support multiple natural language messages.)
Agreed. Seems mad. The only thing I can imagine is that this was originally designed before it was clear that ISO Schematron was a viable language for expressing constraints in such as way that they could be processed through to a schema and acted on by a validator, and therefore the original constraints were expressed only in prose as a sort of placeholder for future work.
participants (3)
-
Lou Burnard -
Martin Holmes -
Syd Bauman