OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Time for Provisional Identifiers? (was RE: [office] Evolving ODF, Interop and Multiple Implementations)


I have two proposals for ODF 1.3 that could benefit from having provisional identifiers established.  These provisional identifiers would be for the following proposed official identifiers:

For ODF 1.3 Protection-Key Enhancements (https://tools.oasis-open.org/issues/browse/OFFICE-3703)

To be reserved:

   http://docs.oasis-open.org/ns/office/1.3/protection#authz160
   http://docs.oasis-open.org/ns/office/1.3/protection#sha1dk

Possible Experimental/Provision namespace for corresponding implementation-defined use in ODF 1.2:

   http://docs.oasis-open.org/ns/office/1.2/x-protection#

For ODF 1.3 Package Encryption Enhancements (https://tools.oasis-open.org/issues/browse/OFFICE-3709):

To be reserved:

   http://docs.oasis-open.org/ns/office/1.3/security#sha1-shaken

Possible Experimental/Provisional namespace for corresponding extended-package use in ODF 1.2:

   http://docs.oasis-open.org/ns/office/1.2/x-security#


[Note: The use of http://www.w3.org/2000/09/xmldsig#hmac-sha1 as an extended value for the manifest:checksum-type attribute does not require an OASIS-defined namespace.]
   
At the time that CSDs of ODF 1.3 Part 1 and ODF 1.3 Part 3 reflect these proposals, a CND could be produced that establishes the experimental use for ODF 1.2 producers and consumers.

[Note: An anticipatory experimental consumer could accept both forms of identifiers but only produce the experimental identifier in ODF 1.2 documents.  An ODF 1.3 consumer could also accept both identifiers but only produce the official form.  In the event that the official form is never  ratified, an ODF 1.3 consumer could continue to produce the experimental identifier in ODF 1.2 (extended) documents and in ODF 1.3 (extended) documents, ad lib.]

 - Dennis

-----Original Message-----
From: office@lists.oasis-open.org [mailto:office@lists.oasis-open.org] On Behalf Of Dennis E. Hamilton
Sent: Monday, October 22, 2012 13:40
To: robert_weir@us.ibm.com; office@lists.oasis-open.org
Subject: RE: [office] Evolving ODF, Interop and Multiple Implementations

Two +1, below

-----Original Message-----
From: office@lists.oasis-open.org [mailto:office@lists.oasis-open.org] On Behalf Of robert_weir@us.ibm.com
Sent: Monday, October 22, 2012 12:25
To: office@lists.oasis-open.org
Subject: RE: [office] Evolving ODF, Interop and Multiple Implementations

office@lists.oasis-open.org wrote on 10/22/2012 01:41:57 PM:

[ ... ]

>  2. Another way to work this is the way that features progress in 
> other venues, such as the IETF.  There is early specification of a 
> feature having mutual interest, but it stays in draft until there 
> are implementations.  It doesn't even get to the equivalent of a 
> Committee Spec until interoperable use is confirmed and the rough 
> edges adjusted, unsupported aspects removed, etc.  And then it rolls
> into a Standard.  This raises some problems around changes over time
> and the management of identifiers and namespaces for XML-based formats though.
> 

[ ... ]

<orcmid rate="+1">

   But there are ways of doing this kind of approach entirely within the TC.  
   For example, we could have a document called    "experimental features" 
   or such that we track as a Committee Draft, even put out for public review,
   but it advances no further until we have multiple implementations. 

</orcmid>

>  3. It appears that another way to work on the lines of (2) would be
> to have provisional features, with provisional identifiers and 
> namespaces, that are not confused with anything in the standard and 
> occur as extensions in implementations.  There is a way to also 
> reserve what would be the adopted identifiers and namespaces, so 
> that supporting consumers could accept either designations, but 
> producers would only use the provisional identifiers and namespaces.
> If the feature doesn't make it into a standard in interoperable form
> with the extension, the reserved designations are never adopted.  
> (The extension remains usable as an extension and there is never any
> confusion with an incompatible variant that makes it into the 
> standard, since that would not conflict with the reserved ones that 
> were not adopted.)
> 

<orcmid rate="+1">

     If the provisional identifiers are not in the standard itself, 
     then that sounds OK.  Otherwise we're just introducing another 
     flavor of extended conformance. 

Right, the provisional identifiers are not in the standard itself and
are always foreign elements, attributes and attribute values with
respect to the schema of the standard.

They could be provided as a companion to the "experimental features"
CD so that there could be experimental interoperability too, but
they never become more than foreign.

</orcmid>

[ ... ]



---------------------------------------------------------------------
To unsubscribe, e-mail: office-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: office-help@lists.oasis-open.org



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]