[Fwd: [office] Open issues for phase 1 exit]

Hi all,

here's a copy of Michael's 'phase 1 exit' document. Please peruse it and 
see if there is anything that should be done in this phase, but is 
missing from the document.

Sincerely,
Daniel

------------------------------------------------
Charts
------
The discussion about charts are in progress. It is the last topic from 
our working package proposal.

Packages
--------
During our discussions I think we assumed that we support packages as 
well as plain XML files, but we didn't agree on the packages themselves. 
They are described in chapter 11 of the OpenOffice.org specification. We 
additionally have to discuss how URL's look like that reference other 
streams within a package.

Namespace URI
-------------
The namespace URIs for the Open Office Format have to be specified. I 
will check whether there is an OASIS recommendation for this. When 
looking at the URIs other TCs use, I assume they have to look like

urn:oasis:names:tc:OpenOffice:1.0:office
urn:oasis:names:tc:OpenOffice:1.0:text

etc.

Related to this is the question whether the namespace URIs we use should 
link to an existing document.

Generator ID
------------
The specification currently does not include a standard way how to 
specify who (or which application) actually saved a document. However, 
there seem to exist situation where a generator ID might be useful. For 
instance, a certain application might have wrongly exchanged the values 
"left" and "right" of an attribute in its import as well as in its 
export of Open Office documents. A generator ID in this case might help 
to resolve this issue without loosing the ability to load the incorrect 
documents correctly from the end users perspective, who never noticed 
this error. The generator ID should include a version for this purpose.

Obviously, each application might add its won generator ID to the meta 
information. However, a standardized way how to specify generator IDs 
might help other applications to load documents that are known to be 
incorrect as well.


Schema language
---------------
At the beginning of our work (at January the 6th) we agreed to use 
Relax-NG as working language, but to deliver DTD and XSD schemas as 
well. We postponed the decision which schema languages should be 
normative until the end of the first phase, where we now are.

Related to this is the question whether there are Relax-NG concepts we 
don't want to use because they cannot be transformed into XSD/DTD, and 
whether we want to specify rules how to use Relax-NG itself. An example 
for this might be the question whether attributes and element contents 
should be specified by separate definitions or might be specified inline:

<define name="text-h">
    <element name="text:h">
        <attribute name="text:outline-level">
            <data type="positiveInteger"/>
        </attribute>
        <ref name="paragraph-attrs"/>
        <zeroOrMore>
            <ref name="paragraph-content"/>
        </zeroOrMore>
    </element>
</define>

is compact and easy to read, while the following might be more extensible:

<define name="text-h">
    <element name="text:h">
        <ref name="text-h-attlist"/>
        <ref name="text-h-content"/>
    </element>
</define>

<define name="text-h-attlist">
    <attribute name="text:outline-level">
        <data type="positiveInteger"/>
    </attribute>
    <ref name="paragraph-attrs"/>
</define>

<define name="text-h-content">
    <zeroOrMore>
        <ref name="paragraph-content"/>
    </zeroOrMore>
</define>


Core Feature Set/Conforming applications
----------------------------------------
In our 28th April meeting we agreed that we won't specify a normative 
core set of elements and attributes, because these would depend on the 
the kind of application (viewing, editing, etc.), and it seems to be 
impossible to cover all of them. Instead of this, we agreed to add a non 
normative appendix to the specification that states for some typical 
application classes what features may, should or must be supported.