Open issues for phase 1 exit

Dear TC members,

below is a list of issues that need to be resolved in addition to 
preparing the specification document and the schemas before we can close 
the first phase of our TC. Please let me know if you detect that 
something is missing.

The list itself isn't very long, so I think if we are lucky, we might be 
able to discuss these things until the christmas break, so that we can 
concentrate our work on preparing and reviewing the specification and 
schemas after the x-mas break. The exception from this might be the 
"Core Feature Set"/"Conforming applications" issue. To address this 
issue, I think it would be best if some of us volunteer to prepare 
proposals for use cases they are familiar with.

Best regards

Michael

-----------------------------------------------

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.