Subject: RE: [Simple] Double specification: text and schema

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 1 Jul 2004 18:12:34 +0100

Although I am not an author of these drafts, I agree strongly with Miguel here.

In fact we already had a similar discussion in the floor control design team in XCON (BNF versus text rather than XML versus text) and came to the same conclusion.

regards

Keith

> -----Original Message-----
> From: Miguel Garcia [mailto:[email-masked]]
> Sent: 01 July 2004 12:10
> To: SIMPLE mailing list
> Subject: [Simple] Double specification: text and schema
> 
> 
> Hi:
> 
> I want to point out an issue I have found when reviewing a 
> few I-Ds that 
> define XML schemas.
> 
> The problem is that many documents do double normative 
> specification: on 
>   one side, they introduce normative text when they describe 
> the various 
> elements that are part of the XML schema; on the other side, the XML 
> schema is normative by itself.
> 
> An example:
> 
> draft-ietf-simple-filter-format-01.txt says in section 3.2
> 
>     The <filter> MUST have an 'id' attribute.  The value of the 'id'
>     attribute MUST be unique within the <filter-set> element.  The
>     <filter> MAY have an 'uri' attribute.  The value of the 'uri'
>     attribute is the URI of the resource which the filter applies to.
>     The <filter> MAY have an 'domain' attribute.  The value of the
>     'domain' attribute is the domain of the resources that the filter
>     applies to.  The "uri" attribute and the "domain" 
> attribute MUST NOT
>     appear together in a filter.
> 
> Then, the XML schema indicates that <filter> MUST have a 
> required 'id' 
> attribute:
> 
>         <xs:attribute name="id"  type="xs:string" use="required"/>
> 
> The schema also says that <filter> MAY have a 'uri' attribute 
> (optional):
> 
>         <xs:attribute name="uri" type="xs:anyURI" use="optional"/>
> 
> 
> And so on.
> 
> The problem: We have two normative statements (one in the 
> text, another 
> in the XML schema) indicating the same thing. This is not a 
> big problem 
> as long as both statements indicate the same thing. But what 
> happens if 
> the document evolves, and then we it is decided to make 
> mandatory some 
> attribute that previously was optional, and what happen if 
> the change is 
> reflected only in the textual form and not in the schema; or 
> vice versa. 
> Then we run into trouble.
> 
> Therefore, I would like to propose that, in the sake of 
> interoperability 
> of implementations, documents indicating XML schemas MUST specify the 
> normative part as much as possible in the XML schema definition. Only 
> those bits that cannot be specified in the schema MUST be 
> specified in 
> the text.
> 
> According to this suggestion, the above paragraph would be 
> re-written as:
> 
>     The <filter> has an 'id' attribute.  The value of the 'id'
>     attribute MUST be unique within the <filter-set> element.  The
>     <filter> has an 'uri' attribute.  The value of the 'uri'
>     attribute is the URI of the resource which the filter applies to.
>     The <filter> has an 'domain' attribute.  The value of the
>     'domain' attribute is the domain of the resources that the filter
>     applies to.  The 'uri' attribute and the 'domain' 
> attribute MUST NOT
>     appear together in a filter.
> 
> Note that the text above still indicates a couple of 
> normative sentences 
> that cannot be expressed (to my knowledge) in the schema.
> 
> Comments? Can we agree this way of working from now on?
> 
> - Miguel
> 
> 
> -- 
> Miguel A. Garcia           tel:+358-50-4804586
> Nokia Research Center      Helsinki, Finland
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 02 Jul 2004 10:41:21 +0300

Hi Keith:

Just to clarify that I was just pointing out one example draft, but I 
believe the problem is spread out across most of the drafts this working 
group is producing.

Therefore, I will urge the working group to take a resolution ASAP that 
could be applied immediately.

- Miguel