Hi Devs & Users,
With the new refactoring of officeimporter module, it's possible to
implement a generic office document converter on top of
xwiki-officeimporter. By a "document converter" I meant an xwiki application
where you can upload a .doc file and get it converted to a .pdf, .odt etc.
Supported formats will be those mentioned in
http://artofsolving.com/opensource/jodconverter/guide/supportedformats and
few more Office2007 formats.
Would this application be a good addition to XWiki?
Thanks.
- Asiri
PS: It would take about 2-3 days to fully implement and test the
application.
They are not using XWiki... yet!
Cheers,
Ricardo
-------- Original Message --------
Subject: [Obo-discuss] CFP: The Future of the Web for Collaborative
Science (FWCS 2010) at WWW'10
Date: Fri, 11 Dec 2009 16:10:54 +0000
From: Jun Zhao <jun.zhao(a)zoo.ox.ac.uk>
Reply-To: obo-discuss(a)lists.sourceforge.net
To: undisclosed-recipients:;
[apologies for cross-posting]
=================================================================================================
CALL FOR PAPERS - International Workshop on The Future of the Web for
Collaborative Science 2010
=================================================================================================
The First International Workshop on The Future of the Web for
Collaborative Science (http://esw.w3.org/topic/HCLS/WWW2010/Workshop),
co-located with WWW'10, April 27 or 28 2010, Raleigh, NC, USA
---------------------------------------------------
INTRODUCTION
The Web was originally invented with the physics community in mind, but
rapidly expanded to include other scientific disciplines, in particular
the health care and life sciences. By the mid 1990s the Web was already
being used to share data by biomedical professionals and
bioinformaticians. The Web continues to be immensely important to these
fields, however use cases have expanded considerably. Researchers are
now looking to share extremely large data sets on the Web, extract
insights from vast numbers of papers cross sub-disciplines, and use
social networking tools to aggregate data and engage in scientific
discussion. Furthermore, individuals are beginning to store their
medical records online, and some are sharing their genetic makeup in a
bid to find others with a similar profile. These use cases are pushing
the boundaries of what is currently possible with the Web. This half-day
workshop will present how scientists are currently using the Web, and
discuss the functionality that is required to make the Web an ideal
platform for both cutting edge scientific collaboration and for managing
health care related data.
The goals of this workshop are the following:
* Foster innovation in applying the latest web technologies to
collaborative HCLS
* Explore HCLS specific requirements for collaborating on the web, e.g.
trust, privacy, intellectual property, knowledge management, and the
scale and diversity of data
* Learn about the latest developments in data modeling, tools and
technologies for web-based collaborative science
* Bridge communication and knowledge transfer between the HCLS and web
communities
---------------------------------------------------
TOPICS FOR PAPER SUBMISSION
We would encourage submission of papers covering the following topics:
* Web 2.0 applications for large, heterogeneous and complex data sets
* Models for collaborative scientific annotations
* Tools and applications for aggregating information across web sites
* Provenance, attribution, trust, and intellectual property
* Policy for data access, sharing, and anonymization
We seek three kinds of submissions:
* Full technical papers: up to 10 pages
* Short technical and position papers: up to 5 pages
* Demo description: up to 2 pages
---------------------------------------------------
SUBMISSIONS
Submitted papers will be refereed by at least three members the Program
Committee. Accepted papers will be published on the workshop web site.
All submissions must be formatted using the WWW2010 templates
(http://www2010.org/www/authors/submissions/formatting-guidelines/). The
address for the online submission system will be published shortly.
---------------------------------------------------
IMPORTANT DATES:
* Submission deadline- February 15, 2010
* Notification of acceptance - March 8, 2010
* Camera-ready version - March 22, 2010
* Workshop date - April 27 or 28, 2010
---------------------------------------------------
Workshop Chairs
Jun Zhao, Oxford University
Kei Cheung, Yale University
M. Scott Marshall, Leiden University Medical Center / University of
Amsterdam
Eric Prud'hommeaux, W3C
Susie Stephens, Johnson & Johnson Pharmaceutical Research & Development
---------------------------------------------------
Programme Committee
* Christopher Baker, University of New Brunswick
* John Breslin, GUI Galway
* Simon Buckingham Shum, Open University
* Annamaria Carusi, Oxford University
* Helen Chen, Agfa Healthcare
* Paolo Ciccarese, Harvard University
* Tim Clark, Harvard Medical School
* Anita de Waard, Elsevier
* Michel Dumontier, Carleton University
* Lee Feigenbaum, Cambridge Semantics
* Timo Hannay, Nature
* William Hayes, BiogenIdec
* Ivan Herman, W3C
* Vipul Kashyap, Cigna
* Nikesh Kotecha, Stanford University
* Phil Lord, University of Newcastle
* Robin McEntire, Merck
* Parsa Mirhaji, University of Texas
* Mark Musen, Stanford University
* Vit Novacek, DERI
* Alex Passant, DERI
* Elgar Pichler, AstraZeneca
* Rosalind Reid, Harvard University
* Patrick Ruch, University of Applied Sciences Geneva
* Daniel Rubin, Stanford
* Matthias Samwald, DERI, Ireland // Konrad Lorenz Institute for
Evolution and Cognition Research, Austria
* Susanna Sansone, EBI
* Nigam Shah, Stanford University
* Amit Sheth, Wright State University
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Obo-discuss mailing list
Obo-discuss(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/obo-discuss
Hi Sergiu,
> /**
> - * @return can current user restore this document from recycle bin
> + * Check if the current user has the right to restore the document.
> + *
> + * @return {@code true} if the current user can restore this document,
> {@code false} otherwise
> * @throws XWikiException if any error
> */
> - public boolean canUndelete() throws XWikiException
> + public boolean canUndelete()
> {
>
This looks like a public API change. You have introduced a checkstyle error
(unused @throws tag) which I fixed since the build was failing. Not sure if
the change of the API is a big deal or not in this case.
- Asiri
Hi devs,
The short version:
Should we always use UTF-8 for encoding and decoding URLs, regardless of
the wiki encoding, for better compliance with web standards?
The long version:
By definition, URLs can only contain ASCII characters, everything else
must be converted to their corresponding bytes and escaped as %XY
escapes. The problem is that "their corresponding bytes" implies a
charset + encoding, and no specification *enforces* a specific pair,
although it is *recommended* to use Unicode + UTF8, to comply with the
modern tendency of the web in general.
Traditionally, XWiki has been using the same encoding as the configured
global wiki encoding for the URLs, which means that before 1.9, when we
switched to UTF8 as the default wiki encoding, all URLs were using the
ISO-8859-1 encoding. Since the switch to UTF-8, URLs are also using the
UTF-8 encoding by default, although the wiki encoding can be changed.
Now, since 2.1, a bugfix accidentally changed the behavior, so that
parsing back URLs always uses the UTF-8 encoding, even though composing
URLs continues to use the wiki encoding. This is a bug, which prevents
changing the encoding to anything other than UTF-8, and it should be fixed.
Now, we have two options:
1. Reintroduce the old behavior, so that URLs always use the wiki
encoding. This is a direct bugfix.
2. Also change the encoding part, so that UTF-8 is always used. This is
an improvement, going towards better compliance with web standards.
Personally I think that the second option is the better one, but it
requires a vote, since it has a few drawbacks.
Advantages:
+ better compliance with web standards, since UTF-8 is the recommended
encoding for URLs (although not imposed)
+ support for a wider range of document names, since UTF-8 allows
full-unicode document names, while ISO-8859-1 limits names to latin1
characters
+ better support from browsers, since entering accented characters
directly in the address bar encodes the URL sent to the server using
UTF-8, and decoding the URL also assumes UTF-8; this means that a
document named "é" will be printed as .../view/Main/%E9 and will have to
be entered the same way in the address bar when ISO-8859-1 is used, and
as .../view/Main/é when UTF-8 is used
Drawbacks:
- by default Tomcat uses ISO-8859-1 as the encoding for URLs, so the
Tomcat configuration will have to be changed as in
http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Encoding#HTomcat
- some existing bookmarks will not work anymore once the encoding is changed
+1 for option 2 from me,
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi,
Since I'm writing the new Model part for Entity References (document
and attachment for now but we can imagine objects and object
properties later on). I'd like to propose 2 things:
* A syntax for escaping special characters in references
* Some changes to the supported reference syntax
Escapes
=======
I'd like to propose using the backslash (i.e. \ ) character.
For example: "a page name with \: some \. special \@ characters"
Rationale:
* it's a well known char for escapes, all devs know about it
* using "~" would be confusing with the wiki syntax
Known issue:
* when in the velocity macro you need to be careful to use a double
escape since \ is the velocity char for escaping. Ex:
{{velocity}}
[[label>>special\\@page-name]]
{{/velocity}}
Breakages
=========
Since we'll know have a generic factory/serializer for all entity
types we need to make the syntax more consistent. This means that the
following syntax will not work anymore:
* ex: "wiki:page". This would be interpreted as a document with a page
of "page" and a space of "wiki:"
* When using the "default" factory, only default values would be used
(right now it's a mix between current doc values and default values).
Suggested defaults: "xwiki" for Wiki, "XWiki" for space, "WebHome" for
page and "" for attachment name. Note that one idea is to make these
defaults configurable in the xwiki config file
* It's hard to know for sure but we certainly have various other
inconsistencies that exist now when using special reserved chars in
references
We have 2 options here:
* Make XE 2.2 not backward compatible for some references. Advertise
it in the release notes and explain to users how they should change
their names if they use "exotic" names
* Create an automatic converter, for example as a database migrator
that would read all documents in the wiki, call getLinks() on each
document, send the links to the old parser (would need to extract it
somewhere and ensure it behaves as now) and send the link to the new
parser and compare. If there's a difference, escape the char and save.
This would also need to be done for document parent references, the
backlink table and all object properties that allow wiki syntax or
velocity. Note that it wouldn't fix any generated name (using velocity
for ex).
The automatic converter option is really hard to do so I'm leaning
more towards the first solution. That would need to be properly
handled since it could potentially cause quite a few broken links.
WDYT?
Thanks
-Vincent
Hi everyone,
Just a quick note to wish everyone in the XWiki project very happy
festivities and a happy next year for 2010.
The XWiki project has seen exciting times in 2009 as described on:
http://massol.myxwiki.org/xwiki/bin/view/Blog/XWikiIn2009
Let's all make 2010 even better :)
Take care,
-Vincent
In current implementation, for a successful upgrade, I have to carefully export:
1. All the pages that I've created
2. All the user profile pages.
3. *.WebPreferences, XWiki.XWikiPreferences.
4. XWiki.XWikiAllGroup, XWiki.AdminGroup
and pray, these pages are compatible with a new version of XE.
As I see, the main headache is that the information about user, group,
preferences spreads in a lot of pages. Why isn't there a central
database to store them, so updating will be much simpler?
--
-- Zhaolin Feng
-- www.mapbar.com
-- Currahee! We stand alone together!