oxf url scheme

> Hi ,
>
> I raised a comment on user-voice but did not understand the reply so
> raise it again here.
>
> I suggested that the oxf: url scheme is not a standard url schema and
> so should be removed from Orbeon, as a barrier to entry.
>
> Alessandro replied:
>
>> Yes, it is non standard, but it does solve a problem.
>> So we won't be planning to remove that namespace.
>> Note however that in most cases you don't have to use the oxf:/ scheme,
>> and can just use a path that starts with /.
>> That should solve the issue you're seeing in Eclipse.
>
> I do not understand what problem it solves.
> Could you explain further?
> Is this related to accessing .xql files from within a jar?
>
> I have not been able to remove the errors reported in Eclipse
> by replacing the urls as suggested.
>
> I much prefer to work with zero errors in Eclipse, so would be grateful for a
> mechanism to avoid this.
>
> cheers
> Tim
>
>
> --
> You receive this message as a subscriber of the [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws
>
>

> Tim,
>
> The problem it solves is one of sandboxing and abstraction. All "oxf:"
> protocols resolve to the Orbeon resource manager, which can access
> resources in JARs, WARs, on the filesystem, etc. See:
>
>  http://www.orbeon.com/orbeon/doc/reference-resource-managers
>
> So you can write oxf:/foo/bar.xml, which can be stored in a JAR file,
> under your c:/drive/path/, in your WEB-INF/resources/, or even in a
> database if you implemented your own resource manager.
>
> Orbeon Forms uses this as well. For example, the Form Runner resources
> are stored within orbeon-form-runner.jar in the distribution, but when
> we develop Form Runner the content of the JAR is stored directly in
> the filesystem.
>
> This also gives you location independence within a filesystem.
>
> Now we could have used "file:" and hack that protocol to implement the
> sandboxing and abstraction layer, but then Eclipse would probably
> still complain about not finding paths since it wouldn't know about
> that either.
>
> Now in may cases you don't need to use the oxf: prefix, since paths
> are relative to their containing documents. So maybe by using relative
> paths Eclipse will be happy.
>
> BTW the following implication:
>
>  non-standard => should be removed
>
> is not really an argument. If we removed everything non-standard in
> Orbeon Forms you couldn't do much with it ;) And the same would apply
> to your favorite web browser or operating system ;)
>
> -Erik
>
> On Wed, May 5, 2010 at 9:19 AM, Tim Pizey <[hidden email]> wrote:
>> Hi ,
>>
>> I raised a comment on user-voice but did not understand the reply so
>> raise it again here.
>>
>> I suggested that the oxf: url scheme is not a standard url schema and
>> so should be removed from Orbeon, as a barrier to entry.
>>
>> Alessandro replied:
>>
>>> Yes, it is non standard, but it does solve a problem.
>>> So we won't be planning to remove that namespace.
>>> Note however that in most cases you don't have to use the oxf:/ scheme,
>>> and can just use a path that starts with /.
>>> That should solve the issue you're seeing in Eclipse.
>>
>> I do not understand what problem it solves.
>> Could you explain further?
>> Is this related to accessing .xql files from within a jar?
>>
>> I have not been able to remove the errors reported in Eclipse
>> by replacing the urls as suggested.
>>
>> I much prefer to work with zero errors in Eclipse, so would be grateful for a
>> mechanism to avoid this.
>>
>> cheers
>> Tim
>>