[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [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.
--- Begin Message ---
- From: Michael Brauer <michael.brauer@sun.com>
- To: office@lists.oasis-open.org
- Date: Thu, 27 Nov 2003 11:32:58 +0100
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. To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/office/members/leave_workgroup.php.--- End Message ---
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]