incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Biao Han <hanb...@cn.ibm.com>
Subject Re: RE: [odftk-dev] Re: request help on ODF data signature issues
Date Fri, 05 Aug 2011 06:14:40 GMT
Agree with supply "standards mode" and "hacks mode". But the default mode
maybe prefer "hacks mode".
We don't want to see that users sign a document using ODF Toolkit, when
open with OOo/LO they find it doesn't work...


> From: Wolf Halton <wolf.halton@gmail.com>
> To: ooo-dev@incubator.apache.org
> Date: 2011-08-04 23:49
> Subject: Re: RE: [odftk-dev] Re: request help on ODF data signature
issues
>
> +1 default_mode=standards_compliant
>
> On Aug 4, 2011 10:50 AM, "Hanssens Bart" <Bart.Hanssens@fedict.be> wrote:
> > Dare I mention "quirks mode" ? :-)
> >
> > In that case, I'd strongly suggest to make the standards mode the
default,
> > not the quirks mode (otherwise it's too easy to let this issue
> proliferate)
> >
> > Bart
> >
> > ________________________________________
> > From: robert_weir@us.ibm.com [robert_weir@us.ibm.com]
> > Sent: Thursday, August 04, 2011 4:36 PM
> > To: dev@odftoolkit.odftoolkit.org; ooo-dev@incubator.apache.org
> > Subject: [odftk-dev] Re: request help on ODF data signature issues
> >
> > So, from the ODF Toolkit perspective, I think it would be best if we
had a
> > flag that the programmer could set, to make it operate in "standards
mode"
> > or "hacks mode" or something like that. It is useful to have a
"reference
> > implementation" mode where it follows the standard strictly. This could
> > be used for interop testing with other products. And it is also useful
to
> > have a mode that is compatible with current OOo/LO.
> >
> > -Rob
> >
> > Hanssens Bart <Bart.Hanssens@fedict.be> wrote on 08/04/2011 05:39:32
AM:
> >
> >> From: Hanssens Bart <Bart.Hanssens@fedict.be>
> >> To: "dev@odftoolkit.odftoolkit.org" <dev@odftoolkit.odftoolkit.org>,
> >> "ooo-dev@incubator.apache.org" <ooo-dev@incubator.apache.org>
> >> Date: 08/04/2011 05:40 AM
> >> Subject: [odftk-dev] Re: request help on ODF data signature issues
> >>
> >> Hi,
> >>
> >> As far as I can tell, these are known implementation issues.
> >> OOo (and most of the other products based on that code base) do not
> >> follow the spec IMHO.
> >>
> >> See also
> >>
> >> https://bugs.freedesktop.org/show_bug.cgi?id=39657 (ds namespace in
> >> LibreOffice)
> >> http://openoffice.org/bugzilla/show_bug.cgi?id=107864 (ds namespace in
> > OOo)
> >> http://openoffice.org/bugzilla/show_bug.cgi?id=66276 (multiple
> >> X509Certificate in OOo)
> >> http://openoffice.org/bugzilla/show_bug.cgi?id=108286
> >>
> >>
> >> Best regards
> >>
> >> Bart
> >>
> >> ----
> >>
> >> From: Biao Han [mailto:hanbiao@cn.ibm.com]
> >> Sent: donderdag 4 augustus 2011 11:19
> >> To: ooo-dev@incubator.apache.org
> >> Cc: dev@odftoolkit.odftoolkit.org
> >> Subject: [odftk-dev] request help on ODF data signature issues
> >>
> >> Hi all,
> >>
> >> I am the Apache ODF Toolkit developer and working on ODF data
> >> signature feature. Several issues need to help.
> >>
> >> 1. Different from other xml file, such as content.xml, why
> >> documentsignatures.xml is not namespace aware? For example,
> >> "Signature" element, only the local name Signature, not including
> >> "ds" namespace.
> >> 2. Why Open Office generates three same content X509Certificate
> >> elements for X509Data in documentsignatures.xml?
> >> 3. How to generate XML ID datatype value? UDDI is too short...
> >> OpenOffice
> > ID_003a00a40036005c0099001b004900a400960062003000c500f900e300af00f7
> >> UDDI ID_79200773-ec61-43d5-b079-a26a081bfb08
> >>
> >> Thanks & Regards
> >>
> >> Biao Han (Devin)
> >> SOA Standards Growth, Emerging Technology Institute(ETI), IBM China
> >> Software Development Laboratory
> >> Tel:(86-10)82450541
> >> Email: hanbiao@cn.ibm.com
> >> Address: 3/F Ring Building, No.28 Building, Zhong Guan Cun Software
> >> Park, No. 8 Dong Bei Wang West Road, ShangDi, Haidian District,
> >> Beijing, P.R.C.100193
> >
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message