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

[robert_weir@us.ibm.com]

<office@lists.oasis-open.org> wrote on 05/04/2013
01:05:03 PM:

> 
> 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.
> 


I think that is the form we would need to take.  We
don't have a concept of a registration authority for identifiers, like
IANA has, or ISO has in some cases (think of language and country codes,
etc.).   So we have "draft" stuff, but "provisional"
is not really a formal status of anything

Note: the order could happen either way.  If
you wanted a CN (or even CS or OS) for "Enhanced encryption in ODF
1.2" that could progress while we still work on ODF 1.3, that is possible
and would likely complete its approval cycle faster than ODF 1.3 will.

-Rob


> [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
withinthe 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
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS
at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>