Subject: Re: [Ecrit] Additional Data XSD Issues

From: Dan Banks <[email-masked]>
Date: Fri, 3 Jun 2016 17:11:59 +0000

Reviewing your concerns and recommendations, here are my thoughts:

2 – regarding the use of complexContent declarations, after reviewing section 2.5.3 of https://www.w3.org/TR/xmlschema-0/ and a few other examples online, I think declaring complexContent with an anyType restriction is actually correct, and that your recommended changes are an equivalent “shorthand” representation that is also acceptable (and easier to read).  I’m in favor of making things easier to read.

Regarding extensibility of xCard, it doesn’t look to me like the schema in RFC 6351 accommodates it, although section 5.1 is very clear that extensibility was intended.  Perhaps this should be reported as an errata on 6351.  We had a similar discussion regarding the extensibility of a type parameter, where an errata was already reported.  This spawned a big discussion about what we should or should not change.  It appears to me that the intended extensibility of vCards is broken in the 6351 schema, and is still broken (at multiple levels) in the schema in the additional data draft.  I don’t know what to do about that, but I agree that an xs:any element probably belongs as one of the repeatable choices in the vcardType definition.

3.1 – I believe the use of choice is correct.  Although the choice itself is only lets you pick one property, you can make as many choices (and in whatever order) you like because the choice is declared with maxOccurs="unbounded".  A sequence requires a specific order, which I believe is incompatible with the intent and schemas of xCard/vCard.

3.2 – As far as cardinality, I think that it should be (in theory) possible to represent in the schema, but it might get ugly.  I see that as an unnecessary complication that goes beyond the schema in RFC 6351, and I think we should avoid attempting to represent it in the additional data version.

3.3 – I believe you are correct that the 6351 schema does not match 6350 definition, and the ‘*’ should not be there.  I think the existing definition in the additional data draft has the equivalent problem by allowing (0 to unbounded).  The way that it includes multiple individual simpleType definitions in the union instead of just enumerating all of the known tokens seems strange to me, but not necessarily incorrect.  I think your suggestion might be technically ok (I’m not sure the sequence is needed), but I think it actually obscures the intent rather than clarifying.  I would prefer to stick to a definition that mirrors 6351 as faithfully as possible.

All of this comes with the usual caveat that I’m not an expert in XML schemas, so I could be mistaken about any of the above.

Dan Banks

From: Ecrit [mailto:[email-masked]] On Behalf Of Philip Reichl
Sent: Wednesday, May 25, 2016 4:42 PM
To: [email-masked]
Subject: [Ecrit] Additional Data XSD Issues

Late last year I started using the schemas from draft-ietf-ecrit-additional-data-37 and found what I believe to be some errors in the XSD included in that document.

I communicated this information directly with the authors and based upon the correspondence I received from on the authors led me to believe that my recommended changes would be included in the next version of the document.

However, when version 38 was published I discovered that it did not include my recommended changes.

The attached PDF file includes a summary of the recommended changes along with the reasoning behind those recommendations. The attached XSD files include the recommended changes, including the one change that was made to the vcard schema in version 38 for the "tel" element.

Can anyone tell me what happened?

--
Philip H. Reichl
Modular Communication Systems
Tel: 818-764-1333 ext. 308