Action Items for todays meeting

[Michael Brauer <michael.brauer@sun.com>]

Dear TC members,

there have been some action items for me for todays meeting. I also 
would like to propose to change the URL schema used within packages from 
what is used in OpenOffice.org.


Change Tracking
---------------
We discussed change tracking for tables on April, the 28th. We clarified 
what the differences to change tracking for text documents are, and we 
have set up the action item to unify these two concepts. We did not 
formally agree that we keep the specification for table change tracking 
unchanged if we do not get a proposal for an unified change tracking for 
whatever reason. Since we decided to move this proposal into the second 
TC phase, I suggest that we agree to today to leave the specification 
for table change tracking unchanged.


Proposal for generator Ids
--------------------------
For the HTTP protocol, the user agent is specified as

User-Agent     = "User-Agent" ":" 1*( product | comment )
product         = token ["/" product-version]
product-version = token

token          = 1*<any CHAR except CTLs or separators>
separators     = "(" | ")" | "<" | ">" | "@"
                       | "," | ";" | ":" | "\" | <">
                       | "/" | "[" | "]" | "?" | "="
                       | "{" | "}" | SP | HT
comment        = "(" *( ctext | quoted-pair | comment ) ")"
ctext          = <any TEXT excluding "(" and ")">

See
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.43
and
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.8
for details

An example for this is

User-Agent: CERN-LineMode/2.15 libwww/2.17b3

This means that the user agents in HTTP can contain an arbitrary number 
of product and product version pairs, but that there is no specification 
what product versions should look like.

I propose that we adopt this user agent syntax as a SHOULD for the 
generator id, where the product version SHOULD additionally allow to 
differ between all versions that get released of a product. This means 
that it should for instance contain a build id if all builds of a 
product are available like this is the case for many open source 
projects, or that it should contain a patch level if different patch 
levels exist for one and the same version of a product. However, since 
these are only SHOULDs, an application might use different generator 
idswhere this is more apropriate.


URLs within packages
--------------------
The OpenOffice.org file format specification does not specify what URLs 
that reference files within a package should look like. However, in the 
OpenOffice.org file format, references to files within a package are 
currently encoded into the fragment identifier. This means that in a 
package that contains the sub files

content.xml
meta.xml
Pitures/Image1.png

the following URL is used to reference Pictures/Image1.gif from inside 
content.xml:

#Pictures/Image1.png.

However, since this might collide with other schemas used inside 
fragment identifiers, I would like to propose to use a URL like

#package( Pictures/Image1.png )

instead. This in fact would be very similar to the XPointer 
specification (http://www.w3.org/TR/xptr-framework/) where the schema is

#xpointer( ... )

What needs to be specified separately is whether the paths within the 
fragment are interpreted as absolute paths with the package root as base 
or as relative paths with the file they are contained in as base. For 
simplicity, I would suggest to interpret them as absolute paths, but to 
specify that they have to start with a "/" so that we can support 
relative paths later on if we want to. The above example then would have 
to be

#package( /Pictures/Image1.png )

In any case, putting paths within packages into fragment identifiers 
means that URLs that reference files outside the package do not need any 
processing an behave as expected. Moreover, the base URL (for non 
package URLS) in all cases would be the package rather than the a file 
within the package. This means that a file "Image2.png" that is located 
next to the package in the file system still could be referenced by the URL

Image1.png

This has the large advantage that in a transformation of a content.xml 
included in a package into for instance HTML, only #package-URLs need 
any special handling. All other URLs do not need any special processing, 
and a differentiation between flat and pacakges office documents is not 
required. Moreover, to resolve a non package URL, it can be passed to 
the operating system unmodified and no knowledge about URL syntax is 
required at all.

A third option where all this is not the case would be to use relative 
URLs within a package where it is assumed that the package behaves like 
a folder in the file system. The above example then would look like

Pictures/Image1.png

but the reference to the a file "Image2.png" located next to the package 
would be

../Image2.png

While this solutions looks very elegant at the first glance, it has the 
severe disadvantages that every URL needs to be checked whether it is a 
reference into the package or not (what is not even trivial) and that 
references to one and the same file would look different in flat and 
packaged office documents. For these reasons, I personally would not 
recommend to use these kind of URLs.

Best regards

Michael