Re: [oic] Template Scenarios - Resilience Testing

[Svante Schubert <svante.schubert@gmail.com>]

On 07.03.2012 18:31, Dennis E. Hamilton wrote:

[More instant design, but something I have thought about a great deal.]

The ODF specification has never had more than about two paragraphs about templates.  Essentially the only specific information is in ODF 1.2 Part 1 section 4.3.2.12 on <meta:template>.  There are some other words that establish different extensions and MIME types for template files.  But nothing about what they are and how they are any different from the document types they are related to.

AFAIK the reason that it is not described in more detail is that the only difference between a template and an ordinary realted mime type document, is that by a usual opening of the document, the document is flagged as new.
As this is application behavior, it has not been specified. Nevertheless IMHO I would provide a little note saying so, otherwise others might be puzzled, too.
BTW editing the template is possible as well, but requires the document in a certain application mode - ie. template editing.

(There's also a glitch in that there was a move to allow (template) documents that have only styles, but the schema does not seem to allow that.  That needs to be double-checked.)

I read the spec that it is possible to have a styles.xml alone in a package, though I would rather have written it using "or" than "and" in:
"
 A.2)the package shall contain at least one of the following files: content.xml and styles.xml. It may contain additional files, including files named settings.xml and meta.xml."
see http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2-part1.html#OpenDocument_Document

With that frugal level of specification, there is an interesting opportunity.

The xlink:href attribute of the <meta:template> element can be a relative reference within the package itself.  That is, an ODF document could well carry the template it was created with/governed by.  To make things easy, that template could even be in the single-XML-file format, rather than requiring a full-up subdocument.  There are cases were a packaged template might be handy, but that could also be embedded as a package (single Zip file) rather than exploded as a subdocument.  In particular, an embedded package could be independently signed.

Pointing at itself with a certain version - as the latest version might no longer be the template - might be possible. Similar the original template residing in the Internet might be pointed out.

This might be relevant in some other discussion that have been going on, both for collaborative honoring of a document profile and for maintaining the integrity/provenance of turnaround documents.

It would be interesting to create some resilience tests just to confirm that having relative <meta:template> xlink:href values and embedded templates doesn't confuse anyone.  An important interoperability case would be to make sure that if the <meta:template> element is preserved, so is the embedded template, even if the consumer-producer made no use of the template.

Let us do some scenarios, I am not certain I fully understand your idea above.
My main scenario was that two ODF applications trying to collaborate should be able to agree easily on the same style set. In addition we have in the back of our mind, that even the feature set might be of interest. I suppose if I am able to work with images and you not and I insert one, my application will tell me that you will not see it. Similar might happen for proprietary fonts that do not exist at my collaboration partners side.

Svante

 - Dennis

-----Original Message-----	
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
Sent: Wednesday, March 07, 2012 08:56
To: 'OIC TC List '
Subject: RE: [oic] Default Styles and Collaboration Profiles

An afterthought:

[This is unabashed instant design, so not to be taken seriously.]

One provision that is not available as part of the ODF specification is a way to have a consumer or consumer-producer signal that it does not (fully) support a feature for which it is indicated that some (collaborative) document depends upon.

To work, such a feature would be one of those SHALL things, or at least a SHALL for implementations that satisfy an important profile.  

The next part is to have a way for a document (template or special profile) to identify what those feature requirements are.

This could just run around in circles.  To have it not do that, there needs to be some very careful analysis and some way to not make this a bigger problem than processing documents themselves [;<).

This might be something for ODF 2.0 someday.  On the other hand, it is a fruitful area for proof-of-concept, early development, etc.  It might make use of the extension provisions of ODF 1.2/1.3 in a benign way.  

 - Dennis

[I really must find a way to wrestle an initial templates scenario to the ground so that there is a place to speak of some of these cases.]  

-----Original Message-----
From: oic@lists.oasis-open.org [mailto:oic@lists.oasis-open.org] On Behalf Of Dennis E. Hamilton
Sent: Wednesday, March 07, 2012 07:55
To: OIC TC List 
Subject: [oic] Default Styles and Collaboration Profiles

The situation with default styles that Svante is concerned about opens up a number of issues around profiling, agreements among collaborators, and whether or not the ODF specification is too liberal in places to allow such agreements to be accomplished reliably.  Or not.

For broad application of ODF, it is clear that some features require a level of implementation-dependence and others might require implementation definition.

An open question is whether or not there is a way to support mechanical honoring (by implementations) of a profile agreement that satisfies a collaboration use case.  Historically, templates are the means for this, but there might not be enough control in the format to enable a standard way to accomplish it.  

It appears that this has to be more grounded in cases to see what principles would apply that allow both continued broad reach of the ODF specification and narrowing to collaboration profiles for some purpose.  Note that this would tend to restrict choice of implementations to ones that honor a profile requirement and, while that might be a means of qualifying implementations for a given collaborative situation, it seems to be rather far from the current state and any ability to qualify implementations in that respect.  

I'm stopping here.  This could easily turn into a boil the ocean problem.  I do think there need to be some limited use cases that are exemplars of practical requirements so the different ways they are achievable can be assessed and any need for a spectrum of practices and technical features explored.

 - Dennis

PS: In the "olden days" of the ISO Open Document Architecture (ODA), there was an application/document profile provision by which a document specified conditions on features that were usable in it.  That is different than a template, although it supported use as a template system as well.  (Nowadays, it would be done with some sort of schema that constrained the document structure, although the general document and schema structure would be well-specified.)  For laughs:
<http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=15926>
<http://en.wikipedia.org/wiki/Open_Document_Architecture> is not great in this case.  ODA was also victim to a format war of the "there shall be only one" variety, with the sort-of opponent being SGML.  Meanwhile, desktop publishing and office document WSYWIG-style editors took over.

PPS: I really just wanted to confirm that I did recover all my notes -- auto-saving of drafts worked -- following my computer crash (tied to something in Skype and my audio hardware/software, I think).


 



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


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