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: RE: Re: [office] DSIG proposal - Application vs. Implementation respecifications


You start with the standard and the scope of the standard.  Behaviors are 
either within scope of the standard, or not within scope.

For items within scope of the standard you have the following kinds of 
behaviors:

Specified -- the things that the standard defines completely.

Unspecified -- the things that the standard allows a conforming 
application to implement as they please.

 Application-defined (synonymous with implementation-defined) -- 
parameters of a standard that are defined and documented by the product 
that conforms to the standard.  In other words, the standard does not 
specify the behavior, but the implementation does. 

Undefined -- Has a more negative meaning than Unspecified, for things like 
division by zero, where we wish to indicate that reliance on specific 
behavior for undefined features will result in non-portable use of ODF. 

The use of in one standard of another standard as a whole, is just a 
normative external reference.  But if you use another standard in part, or 
with qualification, then the definition of how that other standard works 
in your standard is a "profile" of the other standard.

It would certainly be a good thing if, anywhere we we include a standard, 
but with some qualification of it, that we consistently indicate how we 
are profiling that other standard.

-Rob

_
"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 01/07/2009 
06:48:23 PM:
> 
> Um, implementation-specific and application-specific are different for 
me.
> 
> To be clear in this case, specifications such as the one for xml-dsig,
> xml-id, and also URI and IRI, provide for application-specific
> customizations and elaborations.  In this case, incorporation in the ODF
> specification is an *application* relative to those specifications.  ODF
> might provide for further application-specific (e.g., an 
industry-specific
> interoperability profile) and implementation-specific details as well. 
My
> intention was to use application-specific in the sense that 
incorporation in
> ODF is an application of the other specification (not an 
implementation),
> and that profile details are important (especially in the application of 
URI
> segments to elements within a Zip file and generally in the reference to
> PKZip, which covers a lot of things that one hopes not to have to be 
deal
> with in ODF processor).  If I deviated from that objective, it was
> unintentional.
> 
>  - Dennis
> 
> PS: I don't believe that the conformance clauses are approved at this 
point,
> but I don't think that matters to this discussion.
> 
> -----Original Message-----
> From: Jomar Silva [mailto:jomar.silva@br.odfalliance.org] 
> http://lists.oasis-open.org/archives/office/200901/msg00052.html
> Sent: Wednesday, January 07, 2009 14:37
> To: Bob Jolliffee; dennis.hamilton@acm.org; office TC
> Subject: Res: Re: [office] DSIG proposal - URI vs.
> 
> Just a note on Bob's (excellent) answer.
> 
> We already approved the conformance clauses proposed by Michael an we 
have
> there some details about what 'application specific' means for ODF 1.2
> documents (as far as I remember, the definition was Rob's suggestion 
made on
> November, 2008).
> 
> Best,
> 
> Jomar
> 
> [ ... ]
> 
> 
> ---------------------------------------------------------------------
> 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 
> 



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