odb ODF standard conformance [was: minutes of ESC call ...]

[Lionel Elie Mamane]

On Mon, Jan 06, 2014 at 09:45:54PM +0100, Michael Stahl wrote:
> On 20/12/13 14:40, Lionel Elie Mamane wrote:
>> On Thu, Dec 19, 2013 at 08:24:29PM +0000, Michael Meeks wrote:

>>> * Crashtest update (Markus)
>>>     + cf. http://dev-builds.libreoffice.org/crashtest/
>>>       new crash testing result is available (cf. the date & git hash)
>>>       All files tested, and the results are complete for the 1st time.
>>>       and that all odb files are not valid according to the validator
>>>         + need to look at the standard (Lionel)
>>>             + presumably some silly error ...

>> Here are the main classes of "low hanging fruit" conformance errors I
>> see:

>> 1) xlink:href without xlink:type

>>    Easy to fix if (as I assume) I can always put "simple" in these
>>    places. I have a patch sitting in my tree to do that.

> sounds good.

Pushed.

> > 2) manifest:manifest without version attribute: I have no clue what
> >    version I should put there. Any hint?

> to expand on Thorsten's answer, "1.2", but only if that's the ODF
> version; the attribute did not exist in ODF 1.1/1.0.

I don't find how to set the manifest:manifest version. It seems to be
in the GetVersion() of the m_pRootFolder of ZipPackage
(package/source/zippackage/ZipPackage.cxx), but I don't see how that
is ever set except when reading the file (that is, parsing the
manifest). So where/when is it set when *writing* the file?

I pushed a maybe-related fix, but in my testing it still does not set
the version in the manifest... See
http://cgit.freedesktop.org/libreoffice/core/commit/?id=67db0c190ed2fe0629380ca32d153d3f5ab475dc

Help appreciated.

>> 3) ODF mimetype 'application/vnd.oasis.opendocument.base' is invalid

>>    Well,
>>    http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1420388_253892949
>>    lists this as the "recommended" mimetype but that the
>>    RFC4288-registration is "in progress". Shouldn't we rather move
>>    forward on the registration... which has been stalled... why?

> it's more complicated than that: there is a MIME type registration, but
> unfortunately the MIME type registered with IANA is different from the
> one given in the ODF specification... not sure what to do about that.

OK, doing nothing for now.

>> I need help on these:

>> 1) fdo36288-2.odb/forms/Obj42/content.xml[2,17145]:  Error: attribute
>>    "xlink:href" has a bad value: ".uno:FormController/saveRecord" does
>>    not satisfy the "anyURI" type

>>    What is the "right" way to put a .uno URI?

> anyURI is actually an IRI reference in ODF (not that it makes a
> difference here).  RFC3987 says:

>    scheme         = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )

> ... so the problem is that it starts with "." where only ALPHA is
> allowed.  was that perhaps legal in a previous URI RFC or how did we end
> up with this?

<shrug> I don't know the history, but as far as I can see, that's how
UNO commands are stored as a URI; that's also used extensively within
LibreOffice, e.g. to give the action of a toolbar button.

>> 2) ooo103006-1.odb/reports/Obj131/content.xml[2,6115]:  Error: element
>>    "form:hidden" is missing "id" attribute

>>    This one probably just needs an ID generated. Shall we just call
>>    something like BASE64ENCODE(RANDOM(give me 9 bytes))? Or is there a
>>    more structured system in LibreOffice?

> it's a mandatory xml:id attribute with an optional form:id (with same
> value as xml:id) for backward compatibility with ODF 1.1.  the only
> correct way to implement that is via com.sun.star.rdf.XMetadatable,
> which will take care of both uniqueness and persistence.  could possibly
> be tricky though, since no form thingy supports this currently; adding
> whatever hack is used for other form:* may be easier.

<sigh> Dunno. I'll try to take another look one of these days in the
indeterminate future.

>> I doubt that these actually come from base-specific code, but who
>> knows:

>> 1) forms/Obj11/styles.xml:  Error: unexpected attribute "style:layout-grid-snap-to-characters"

> see c1e1ef80e8428514499b061e00801a6a6298d0b0

OK, doing nothing about that.

>> 2) fdo36288-2.odb/content.xml[2,2887]:  Error: tag name
>>    "db:font-charset" is not allowed. Possible tag names are:
>>    <character-set>,<table-settings>

> dbaccess/source/filter/xml/xmlExport.cxx:        SvXMLElementExport
> aElem(*this,XML_NAMESPACE_DB, XML_FONT_CHARSET, sal_True, sal_True);

> guessing maybe it should be db:character-set?

Dunno. I'll try to take another look one of these days in the
indeterminate future. Don't want to blindly change it without
understanding it a bit.

-- 
Lionel