Conformance class attribute proposal (DR 08-0012)

[Jesper Lund Stocholm]

Hi all,

 

Attached is a more concrete and elaborate edition of the proposal from Shawn and I to delete the conformance-attribute and add a new version attribute instead. It should give you an idea of the actions needed.

 

Jesper Lund Stocholm
ciber Danmark A/S

From: Jesper Lund Stocholm [mailto:jesper.stocholm at ciber.dk] 
Sent: Thursday, June 11, 2009 9:25 AM
To: SC 34 WG4
Subject: Conformance class attribute proposal (DR 08-0012)

 

Conformance attribute proposal:

 

Shawn and I have thought about the conformance attribute - especially in the light of the changed namespace for strict documents.

 

We'd like to propose the following change:

 

1.       remove the conformance clause attribute that was created during the BRM

2.       Add a new optional "version"-attribute on the root elements, i.e. for WordProcessing, Presentation and Spreadsheet-documents.

 

Rationale:

The conformance clause was added to be able to distinguish between documents of different conformance classes - a proposal created at the BRM. Now that we have created an even stronger tool (changing the namespace for strict documents) we don't need this attribute any more. Further - should it remain, it would be a source of ambiguity while allowing a strict document (namespace-wise) to specify a conformance class value of "transitional". What we do need, however, is a way to specify versioning of the applied specification.

 

So - there are all sorts of nitty-gritty details to how to do the version-attribute. A suggestion would be to have the constraints on the attribute vary between strict and transitional schemas. So the version attribute could be created as this

 

strict

default: 1.1 IS29500:2008

constrain: MinInclusive="1.1", type="xs:double"

 

We could have the spec specify that these values are reserved:

 

1.1: IS29500

1.2: IS29500 (amd/cor 1)

 

transitional

default: 1.0 (ECMA-376 1st ed)

constrain: MinInclusive="1.0", type="xs:double"

 

We could have the spec specify that these values are reserved:

 

1.0: ECMA-376 1st ed

1.1: IS29500

1.2: IS29500 (amd/cor 1)

 

The important thing at this point is not the details (we'll sort these out in Copenhagen) but to get a consensus that this is a path we should proceed on.

 

Jesper Lund Stocholm
 
Lautruphøj 1-3
DK-2750 Ballerup
Denmark

Tlf.: +45 30 94 55 70
Email: jesper.stocholm at ciber.dk <mailto:jesper.stocholm at ciber.dk> 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20090621/41aa31c7/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 2609 bytes
Desc: image001.gif
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20090621/41aa31c7/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Proposal for Part 1 and Part 4 Conformance-version Attribute Changes .pdf
Type: application/octet-stream
Size: 434094 bytes
Desc: Proposal for Part 1 and Part 4 Conformance-version Attribute Changes .pdf
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20090621/41aa31c7/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Proposal for Part 1 and Part 4 Conformance-version Attribute Changes .docx
Type: application/octet-stream
Size: 29110 bytes
Desc: Proposal for Part 1 and Part 4 Conformance-version Attribute Changes .docx
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20090621/41aa31c7/attachment-0001.obj>