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 _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice