I fixed the issue by copying the definition of xml:space into the IF

See http://svn.apache.org/viewvc?rev=1304524&view=rev


On 24/02/12 15:29, Vincent Hennebert wrote:
> On 16/02/12 10:23, mehdi houshmand wrote:
>> Hi,
>> I was running o.a.f.intermediate.IFParserTestCase in Eclipse, and
>> found it extremely frustrating that the schema (xml.xsd) had to be in
>> the same folder as the test class?!?! Why? It means, if I want to run
>> said test with the Eclipse Junit Runner, I have to copy it into the
>> proper directory, manually.
> ‘ant setup-xml-schema’ does that for you and you should have to run it only
> once per local copy.
>> In related news, when I run "ant junit",
>> it chokes every time for a minute on checking the cached xsd file. I
>> mean, it's obviously not the end of the world, but it is annoying and
>> I'm questioning if it's necessary?
> I’m facing the same issue and it’s certainly suboptimal. I’m still unsure
> about the proper way to solve it though.
>> Gump fails, periodically because of this same issue, which is annoying
>> at best, and quite dangerous since false positives on a CI server... I
>> don't need to preach to the choir here. Can we not assume that the
>> normal W3C software license [1] applies here? If not, their document
>> license [2]? If so, as per the Apache legal recommendations [3], we're
>> thumbs up for distributing this file (with the notice). If either of
>> those assumptions aren't valid, I'd be happy to ask the Apache legal
>> team, they can at least resolve the ambiguity about the license.
>> Just wanted to know your thoughts? This has been bugging me for a while...
> I investigated the issue again some time ago and couldn’t reach any definite
> conclusion.
> AFAICT the XML schema is published under the W3C Document License, due to the
> absence of explicit notice and as per [1]. I don’t think it’s covered by the
> W3C Software License because that would allow to modify the schema and would
> kill the purpose of the standard (the ‘interoperability problems’ mentioned in
> [1]).
> ATM and AFAICT, it’s unclear whether we are allowed to publish material under
> the W3C Document License. I’ve been watching the two following legal issues on
> JIRA but they haven’t been resolved yet:
> https://issues.apache.org/jira/browse/LEGAL-109
> https://issues.apache.org/jira/browse/LEGAL-111
> At any rate, ATM we don’t comply with the requirements prescribed by the W3C
> Document License [2]. Yet we have a copy of xml.xsd in
> src/documentation/intermediate-format-ng. I think we cannot release FOP until
> this has been resolved.
> As for a solution, the simplest probably is to rewrite the part of the XML
> schema that is of interest to us. This may be as simple as rewriting the
> definition of xml:space, but I haven’t tested it.
> [1] http://www.w3.org/Consortium/Legal/IPR-FAQ-20000620#Which
> [2] http://www.w3.org/Consortium/Legal/2002/copyright-documents-20021231
> Vincent
>> Mehdi
>> [1] http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231
>> [2] http://www.w3.org/Consortium/Legal/2002/copyright-documents-20021231.html
>> [3] http://www.apache.org/legal/resolved.html#category-a
>> On 10 November 2011 12:20, Vincent Hennebert <vhenneb...@gmail.com> wrote:
>>> On 10/11/11 09:31, Simon Pepping wrote:
>>>> It is not a good idea to fetch xml.xsd from W3C each time. Put it in
>>>> the sources and if necessary use a catalog. xml.xsd is already
>>>> available at src/documentation/intermediate-format-ng/xml.xsd.
>>> Hmmm. Apparently Gump deletes the workspace directory before every
>>> build, which pretty much kills the benefits of the caching process that
>>> I had put in place in rev. 1186858.
>>> FWIW, I did have in mind to use a catalog, but AFAICT the catalog-based
>>> resolver available from XML Commons Resolver is not compatible with what
>>> is used by XML Schema (org.w3c.dom.ls.LSResourceResolver vs
>>> org.xml.sax.EntityResolver or javax.xml.transform.URIResolver). Also,
>>> using a catalog seemed a bit overkill for this.
>>> Storing xml.xsd locally is an option, but:
>>> • we lose the link to http://www.w3.org/2001/xml.xsd (although I suppose
>>>  we can say that it’s obvious from looking at the content of the file)
>>> • if the original schema ever gets updated, we get out of sync (although
>>>  I suppose that’s unlikely to happen)
>>> • most of all, are we allowed to redistribute this file? I couldn’t find
>>>  any license information with it.
>>> For those reasons I chose to download it into some cache directory.
>>> I could remove this caching mechanism and point to
>>> src/documentation/intermediate-format-ng/xml.xsd instead, if bullet 3
>>> above is not an issue.
>>> Thoughts?
>>> Thanks,
>>> Vincent
>>>> Simon
>>>> On Thu, Nov 10, 2011 at 08:27:53AM +0000, Jeremias Maerki wrote:
>>>>> To whom it may engage...
>>>>> This is an automated request, but not an unsolicited one. For
>>>>> more information please visit http://gump.apache.org/nagged.html,
>>>>> and/or contact the folk at gene...@gump.apache.org.
>>>>> Project xml-fop-test has an issue affecting its community integration.
>>>>> This issue affects 1 projects,
>>>>>  and has been outstanding for 61 runs.
>>>>> The current state of this project is 'Failed', with reason 'Build Failed'.
>>>>> For reference only, the following projects are affected by this:
>>>>>     - xml-fop-test :  XSL-FO (Formatting Objects) processor
>>>>> Full details are available at:
>>>>>     http://vmgump.apache.org/gump/public/xml-fop/xml-fop-test/index.html
>>>>> That said, some information snippets are provided here.
>>>>> The following annotations (debug/informational/warning/error messages) 
>>>>> were provided:
>>>>>  -INFO- Failed with reason build failed
>>>>>  -INFO- Project Reports in: 
>>>>> /srv/gump/public/workspace/xml-fop/build/test-reports

Reply via email to