xsltforms-support — XSLTForms support list

[Xsltforms-support] XSLTForms on smartphone

[Santosh C. <san...@gm...>]

Alain and Friends,
Just tried Our application on Android phone browser and the results are
amazing. I am really excited to share that it works great. Only things which
I did not found working are -
1. Applets for loading and saving data and images which I am sure will find
something with the native Android stuff
2. TinyMCE editor

I will try it on i-phone also, has anyone tried it on iphone other devices
already?

Regards,
Santosh

Re: [Xsltforms-support] Generating HTML view stylesheet from XForms with the help of XSLTForms.xsl

[Dan M. <dan...@gm...>]

If you are just viewing an XML instance without re-ordering any nodes, you
can do this with just a simple generated CSS file.  No XSL is needed.  So
are you thinking of using XSL to generate the CSS file?

- Dan

On Thu, Sep 8, 2011 at 6:44 AM, Santosh Chandak <san...@gm...>wrote:

> Hello Alain and Friends,
>
> I am thinking of this idea about generating a stylesheet from XForms
> definition with the help of which one should be able to view any XML
> instance for which the xforms was created. XSLTForms.xsl already creates
> HTML view which is HTML and Javascript. My requirement is just to generate
> single XSL file for viewing the instance XML file in browser (View only).
>
> XForm input * Transform (like xsltforms.xsl) = Result XSL
> XML Instance * Result XSL = View HTML (similar to what XSLTForms provides
> but view only. No javascript)
>
> I was wondering if I could learn from XSLTForms.xsl and remove the
> javascript components to generate the Result XSL. This would be generic
> enough to work for any XForm and instance XML.
> Any thoughts?
>
> Regards,
> Santosh
>
>
> ------------------------------------------------------------------------------
> Doing More with Less: The Next Generation Virtual Desktop
> What are the key obstacles that have prevented many mid-market businesses
> from deploying virtual desktops?   How do next-generation virtual desktops
> provide companies an easier-to-deploy, easier-to-manage and more affordable
> virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
> _______________________________________________
> Xsltforms-support mailing list
> Xsl...@li...
> https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>
>


-- 
Dan McCreary
Semantic Solutions Architect
office: (952) 931-9198
cell: (612) 986-1552

[Xsltforms-support] Generating HTML view stylesheet from XForms with the help of XSLTForms.xsl

[Santosh C. <san...@gm...>]

Hello Alain and Friends,

I am thinking of this idea about generating a stylesheet from XForms
definition with the help of which one should be able to view any XML
instance for which the xforms was created. XSLTForms.xsl already creates
HTML view which is HTML and Javascript. My requirement is just to generate
single XSL file for viewing the instance XML file in browser (View only).

XForm input * Transform (like xsltforms.xsl) = Result XSL
XML Instance * Result XSL = View HTML (similar to what XSLTForms provides
but view only. No javascript)

I was wondering if I could learn from XSLTForms.xsl and remove the
javascript components to generate the Result XSL. This would be generic
enough to work for any XForm and instance XML.
Any thoughts?

Regards,
Santosh

Re: [Xsltforms-support] [Exist-open] xforms-link-exception and error msg is "Schema not found"

[Alain C. <ala...@ag...>]

Hi,

The noticed exception is typically thrown when a resource cannot be 
obtained from the server.

You could try to get the corresponding file by directly typing its path 
in the location bar of your browser. Maybe using the network log of your 
browser debugger would show you what the server response is.

-Alain

Le 05/09/2011 15:27, srinivasan krishnamoorthy a écrit :
> hi all,
>
> I am using,
>
> Data base : eXist-1.4.1
>
> when i am refresh my form it shows following error
>
> *XSLTForms Exception
> --------------------------
>
> Error initializing :
>
>
>
> xforms-link-exception
>
>
> *and also shows following error msg
>
> *Schema batch.xsd not found*
>
>
> i am alredy keep batch.xsd file in same collection and also i am try 
> to place it in xsltforms collection even though i faced same error....
>
> and the same setup properly work in eXist-1.4.0 version but not in 
> eXist-1.4.1 version it shows above error...
>
> any one give me solution advance thanks to you....
>
>
> -- 
> - With Regards
>
> Srinivasan Krishnamoorthy
>          Dindigul
>

Re: [Xsltforms-support] title attribute of HTML option

[Alain C. <ala...@ag...>]

Hello,

I'm not sure that the title attribute is well supported by every browser.

Generating it with XSLTForms needs to change the XSLT stylesheet 
(xsl:template match="xforms:item").

-Alain

Le 05/09/2011 10:00, Ruslan Forostyanov a écrit :
> Hi guys!
> I have select1/itemset/label/value xform structure.
> What is the best way to get title attribute in generated select option.
>
> <select class="xforms-value">
> <option id="xf-itemset-0" value="1" title="ORIGINAL TEXT HERE">CUTTED 
> TEXT HERE...</option>
> <option id="clonedId0" cloned="true" oldid="xf-itemset-0" 
> value="2">2</option>
>    ...
> </select>
>
> Ruslan
>

Re: [Xsltforms-support] indirect indexing through an instance: what is it supposed to do?

[Alain C. <ala...@ag...>]

Hello Efraim,

According to XPath 1.0, "A PredicateExpr 
<http://www.w3.org/TR/xpath/#NT-PredicateExpr> is evaluated by 
evaluating the Expr <http://www.w3.org/TR/xpath/#NT-Expr> and converting 
the result to a boolean. If the result is a number, the result will be 
converted to true if the number is equal to the context position and 
will be converted to false otherwise; if the result is not a number, 
then the result will be converted as if by a call to the *boolean 
<http://www.w3.org/TR/xpath/#function-boolean>* function. Thus a 
location path |para[3]| is equivalent to |para[position()=3]|."

Thus, I think this is a correct behavior for XSLTForms because a node 
has always a text value.

With XPath 2.0, types are associated to values so a number value would 
not need a cast.

Thanks!

-Alain

Le 05/09/2011 00:15, Efraim Feinstein a écrit :
> Hi,
>
> I'm attaching a test case for a possible bug in XSLTForms. An indirect 
> reference to an item in a nodeset through a numeric index stored in an 
> instance fails (by referencing the first item) unless the index is 
> explicitly typecast to be a number.
>
> The examples I give are:
>  Direct: <xf:output ref="instance('data')//html:ul/html:li[2]"/><br/>
>  Indirect (without a cast): <xf:output 
> ref="instance('data')//html:ul/html:li[instance('index')/n]"/><br/>
>  Indirect (cast to a number): <xf:output 
> ref="instance('data')//html:ul/html:li[number(instance('index')/n)]"/>
>
> There are two ways the test in the "Indirect (without a cast)" case 
> can be interpreted, though: Take the value, cast it to a number and 
> treat it as an index (what I want it to do), or treat the index as a 
> node test; if the node exists/is > 0, evaluate to true(), otherwise, 
> evaluate to false(). I'm not sure which would be the correct behavior 
> in XPath 1.0!
>
> I'm using the latest XSLTForms from svn (rev 508)
>
> Thanks,
>

[Xsltforms-support] xforms-link-exception and error msg is "Schema not found"

[srinivasan k. <sri...@gm...>]

hi all,

I am using,

Data base : eXist-1.4.1

when i am refresh my form it shows following error

*XSLTForms Exception
--------------------------

Error initializing :



xforms-link-exception


*and also shows following error msg

*Schema batch.xsd not found*


i am alredy keep batch.xsd file in same collection and also i am try to
place it in xsltforms collection even though i faced same error....

and the same setup properly work in eXist-1.4.0 version but not in
eXist-1.4.1 version it shows above error...

any one give me solution advance thanks to you....


-- 
- With Regards

         Srinivasan Krishnamoorthy
         Dindigul

[Xsltforms-support] title attribute of HTML option

[Ruslan F. <fo...@gm...>]

Hi guys!
I have select1/itemset/label/value xform structure.
What is the best way to get title attribute in generated select option.

<select class="xforms-value">
 <option id="xf-itemset-0" value="1" title="ORIGINAL TEXT HERE">CUTTED TEXT
HERE...</option>
 <option id="clonedId0" cloned="true" oldid="xf-itemset-0"
value="2">2</option>
   ...
</select>

Ruslan

[Xsltforms-support] indirect indexing through an instance: what is it supposed to do?

[Efraim F. <efr...@gm...>]

Hi,

I'm attaching a test case for a possible bug in XSLTForms. An indirect 
reference to an item in a nodeset through a numeric index stored in an 
instance fails (by referencing the first item) unless the index is 
explicitly typecast to be a number.

The examples I give are:
  Direct: <xf:output ref="instance('data')//html:ul/html:li[2]"/><br/>
  Indirect (without a cast): <xf:output 
ref="instance('data')//html:ul/html:li[instance('index')/n]"/><br/>
  Indirect (cast to a number): <xf:output 
ref="instance('data')//html:ul/html:li[number(instance('index')/n)]"/>

There are two ways the test in the "Indirect (without a cast)" case can 
be interpreted, though: Take the value, cast it to a number and treat it 
as an index (what I want it to do), or treat the index as a node test; 
if the node exists/is > 0, evaluate to true(), otherwise, evaluate to 
false(). I'm not sure which would be the correct behavior in XPath 1.0!

I'm using the latest XSLTForms from svn (rev 508)

Thanks,

-- 
---
Efraim Feinstein
Lead Developer
Open Siddur Project
http://opensiddur.net
http://wiki.jewishliturgy.org

[Xsltforms-support] xsltforms and MarkLogic submission

[<mcu...@co...>]

I am attempting to use MarkLogic and xsltforms to load data from an xml file (stored in a MarkLogic database) into the form, edit the data in the form, and then save the edited xml file back to the MarkLogic database. 

I have created the database and the HTTP server. The form correctly reads the data from the database file ('/test/data.xml') and loads it into the form in the browser. 

The part that does not work is saving the edited file back to the MarkLogic database (<xf:submission method="put"/>). Can someone explain to me how to enable the submission? Does it depend on webdav? What are the setup steps? 

The xquery is below. 

Thanks, 
Morgan Cundiff 

---------------------------- 

xquery version "1.0-ml"; 
declare namespace xdmp=" http://marklogic.com/xdmp "; 

let $page := 
(xdmp:set-response-content-type("application/xml"), 
<html 
xmlns=" http://www.w3.org/1999/xhtml " 
xmlns:xf=" http://www.w3.org/2002/xforms " 
xmlns:xs=" http://www.w3.org/2001/XMLSchema " 
xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance "> 
<head> 
<title>Submission with get and put</title> 
<xf:model> 
<xf:instance id="data-instance" src="/test/data.xml" xmlns="" /> 
<xf:submission id="read-from-file" method="get" 
action="/test/data.xml" replace="instance" instance="data-instance" /> 
<xf:submission id="save-to-file" method="put" 
action="/test/data.xml" replace="instance" instance="data-instance" /> 
</xf:model> 
</head> 
<body> 
<p>Demonstration of using XForms to get and put data to ML database using the submission element.</p> 
<xf:input ref="Element1"> 
<xf:label>Element 1:</xf:label> 
</xf:input> 
<br /> 
<xf:input ref="Element2"> 
<xf:label>Element 2:</xf:label> 
</xf:input> 
<br /> 
<xf:input ref="Element3"> 
<xf:label>Element 3:</xf:label> 
<br /> 
</xf:input> 
<xf:submit submission="read-from-file"> 
<xf:label>Reload</xf:label> 
</xf:submit> 
<xf:submit submission="save-to-file"> 
<xf:label>Save</xf:label> 
</xf:submit> 
</body> 
</html>) 


let $xslt-pi := processing-instruction xml-stylesheet {'type="text/xsl" href="xsltforms/xsltforms.xsl"'} 



return ($xslt-pi, $page) 

------------------------------------- 

Re: [Xsltforms-support] Accessing first element of drop down list.

[Dan M. <dan...@gm...>]

I am not exactly sure of your question since the line "set the first item
value" is not clear to me.  But to trigger an event when the form first
loads you can use the "xforms-read" event.

here is an example that will set the cursor position after a form is first
loaded::

<xf:action ev:event="xforms-ready">
      <xf:setfocus control="first-field" />
   </xf:action>

Here is a full example from the XForms Wikibook:

http://en.wikibooks.org/wiki/XForms/Setting_Initial_Curso

I don't know if the current version of XSLTForms supports the setfocus
element yet, but this is how you use the xforms-read event.

- Dan

On Thu, Aug 11, 2011 at 7:12 AM, bharat darakh <dar...@gm...>wrote:

> My Drop down list is set on "change" event so it retrieves value only if I
> change the item from list.
> But I have to  set the first item value from drop down list
> How could I do this .
> Please help me.
> Thanks.
>
>
>
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it.
> http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Xsltforms-support mailing list
> Xsl...@li...
> https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>
>


-- 
Dan McCreary
Semantic Solutions Architect
office: (952) 931-9198
cell: (612) 986-1552

[Xsltforms-support] Accessing first element of drop down list.

[bharat d. <dar...@gm...>]

My Drop down list is set on "change" event so it retrieves value only if I
change the item from list.
But I have to  set the first item value from drop down list
How could I do this .
Please help me.
Thanks.

[Xsltforms-support] Namespace bugs in different browsers with xsltforms-508

[Leigh L K. Jr <lei...@xe...>]

Given this instance data:

<?xml version="1.0" encoding="UTF-8"?>
<data>
<doc>
<div xmlns="http://www.w3.org/1999/xhtml">
<p>Hi there</p>
</div>
</doc>
</data>

xsltforms-508 in all browsers tested (FF5, Chrome13, IE8) will match
<group ref="doc/div" />
even though the div is in another namespace.

Also, FF5 fails to match this:
<group ref="doc/h:div" />

See attached files.

Leigh.

[Xsltforms-support] submission/@mode vs submission/@ajx:synchronized

[Leigh L. K. Jr. <Lei...@Xe...>]

I see xsltforms.xsl mentions the Ajaxforms extensions 
submission/@ajx:synchronized boolean, and submit/@ajx:synchronized 
boolean, but doesn't handle XForms 1.1 submission/@mode="synchronous" or 
submission/@mode="asynchronous".

Is this a mistake or is ajx:synchronized different from XForms 1.1 
submission/@mode?

Leigh.

[Xsltforms-support] using treeview after response from service

[Steiner, D. J. (LNG-DAY) <Dav...@el...>]

Hi,

I'm trying to incorporate the jquery treeview into my xsltforms page.  I have a service that will return the html structure that's required to make treeview work - I know this because I can take the data that comes out of the service and put it in the body of an HTML document and it works fine.
I'm assuming that this has something to do with the fact that my script in my xsltform only has:
  $(document).ready(function(){
    $("#theList").treeview();
  });

So it seems that I need invoke the treeview function after xsltforms has finished calling the service and xf:output has "rendered" the results from the service.

If I cut and paste the results from the service into a model instance in the xsltform, the functionality of the treeview seems to work, but the styling isn't quite right.  So, I am assuming that this is because the "ready(function)" in the script has worked for the most part, though it appears that the xsltforms styling has overshadowed the treeview styling.

Is there a way to get the treeview styling and functionality in the xf:output of the xsltform?

Sorry if this is obvious, but I'm not much of an html/javascript/css coder...
Thanks,
David

[Xsltforms-support] Question on how index() function changes after insert and deletes

[Dan M. <dan...@gm...>]

Hi all,

We are working on a queue management user interface and we have the
basics of it working here:

http://en.wikibooks.org/wiki/XForms/Queue_Management

There is a working demo here:

http://demo.danmccreary.com/rest/db/dma/apps/xforms-examples/data/15-patterns/08-queue-management/edit-queue.xq

You will note you can move items up, down or to the top of the queue.

Although the basic operations for moving items up and down the queue
seem to work, we are getting some odd behavior about the index() not
staying on the selected row.  This is very understandable since we are
doing inserts and deletes on the rows.  But we were just wondering if
there is some way to keep the index() function on the selected trigger
which seems to stay selected correctly but the index() function does
not..

Thanks! - Dan

-- 
Dan McCreary
Semantic Solutions Architect
office: (952) 931-9198
cell: (612) 986-1552

Re: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types

[Philip F. <Phi...@ma...>]

Conal,

Thank you for that, I will join the list.


Regards

Philip
________________________________________
From: Conal Christopher Tuohy [con...@ve...]
Sent: 23 July 2011 15:53
To: Philip Fennell; xsl...@li...
Subject: RE: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types

The other list I mentioned is this one: http://discussions.blackmesatech.com/listinfo.cgi/xforms-blackmesatech.com

"This discussion list hosts general discussions of XForms, both theoretical and practical. Particular emphasis is placed on questions of how best to use XForms to achieve particular ends and how to solve problems with XForms.

Discussions that are focused on the current work of the W3C Forms working group should take place on www...@li..., and discussions that are specific to the behaviors of particular XForms processors should take place on product-specific mailing lists. But general product-independent discussions of how to do specific things with XForms and general debugging questions are in order."
________________________________________
From: Philip Fennell [Phi...@ma...]
Sent: Saturday, 23 July 2011 1:43 AM
To: Conal Christopher Tuohy; xsl...@li...
Subject: RE: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types

Conal,

> I wonder if the new xforms-users list is a more appropriate form

Can you be more specific about the xforms-users list. I've done a quick search but found nothing matching that name.


> I don't really see that it's relevant whether the XHTML+XForms document
> includes an editable XML instance by inclusion or by URI reference.

Taken in isolation, I can also see that, as part of the transformation that generates a resource's representation, it is a moot point as to whether the resource is included in-line in an XForm or, by reference, out-of-line.

I will post a question to the www...@w3... e-mail list to start a discussion about this notion of whether an XForm is a representation of or an application for a resource.


Regards

Philip


-----Original Message-----
From: Conal Christopher Tuohy [mailto:con...@ve...]
Sent: Friday, July 22, 2011 2:08 PM
To: Philip Fennell; xsl...@li...
Subject: RE: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types

Hi Philip

It would be nice if XSLTForms had a complete implementation of XForms 1.1, and if I could use the xf:header feature it would solve my problem, but I think for a 1.0 implementation it does still make sense not to accept a content-type of "text/html" or "*/*" or in general anything other than XML. Unless XSLTForms provides an explicit Accept header when loading an instance, it may accidentally pass on the browser's default Accept header, and for resources which support content negotiation, that not ideal.

On the theoretical point; I think it's an interesting point, but personally do tend to think that an XForm editor for a resource is a perfectly good "representation" of that resource. I don't really see that it's relevant whether the XHTML+XForms document includes an editable XML instance by inclusion or by URI reference. I see it as analogous to a situation where you might get a representation of an image using an Accept header of "image/*" and retrieve e.g. a PNG file, or get a representation with Accept: text/html and retrieve a web page containing a reference to that same PNG representation. I agree that from a theoretical point of view the HTML XForm should not be seen as an HTML representation of an "XML resource". In the web architecture the "resource" itself is something abstract (it's information about a person or information, in this case), and the XML instance is just a representation of that resource. The XForm is also a representation of that same abstract information resource: it's a two-tiered representation in that it transcludes another representation (a RIF-CS XML record), but that pattern is not unusual on the web, actually.

I'm keen to continue discussing the web-architecture aspect of this, though ... I wonder if the new xforms-users list is a more appropriate form, since it's not really specific to XSLTForms.

Regards

Con

________________________________________
From: Philip Fennell [Phi...@ma...]
Sent: Friday, 22 July 2011 7:12 PM
To: Conal Christopher Tuohy; xsl...@li...
Subject: RE: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types

Conal,

Firstly, to my knowledge, the xf:submission element's xf:header element is not currently supported by XSLTForms. This would be the way to specify the Accept header for your requests, but, more importantly, there is a refinement to the use of the xf:header element that affects how they are set by the client. The 'combine' attribute is created to deal with the situation where you want to either add or override the existing header sent by the client. In your case, you would have to use combine="replace" to ensure only the requested content-type is sent. The other options are 'append' and 'prepend' so that you can define how your value is added to an existing header.

Secondly, and I know this might sound a bit nit-picky but, from the way I tend to look at things, I would regard an XForm application and the instance data it loads as two separate resources. The XForm is not an HTML representation of the XML instance data resource it loads. Also, for XSLTForms, the response has to be application/xml in order that the browser will act upon the xml-stylesheet processing instruction. Now, the server is not bound to honour the request's Accept header, it can give either the best it can or say 'Not Acceptable' so just because it asks for HTML doesn't mean it will receive it.

A document, transformed into an HTML Form, that contains the data from the document might be regarded as a text/html representation of that data, but I'm not convinced that you can argue the same for an XForm document that references the document.

I think there is potential ambiguity in the design that you are using which could lead people to say that it is not truly RESTful.

Some people suggest using a type attribute on the Accept header value to extend its meaning. For example, an Atom Feed has a content type of application/atom+xml where as a single Atom Entry is application/atom+xml;type=entry

Maybe, you could use a content type of application/xml;type=edit. This might be a more flexible solution as it would still give you the possibility of requesting an HTML representation that wasn't editable.

I'd be interested in your thoughts on this as it is potentially a common problem with developing for XForms.


Regards

Philip




-----Original Message-----
From: Conal Tuohy [mailto:con...@ve...]
Sent: Friday, July 22, 2011 7:08 AM
To: xsl...@li...
Subject: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types

I have been using XSLTForms recently, for editing XML metadata records.

In our project, we have a RESTful web service (based on a Fedora
repository) which uses HTTP Content Negotiation to publish different
representations of a resource (i.e. using the same HTTP URL, but in
response to different HTTP Accept headers).

Each resource may be represented as an XML metadata record or as an
XForm, depending on the content-type requested. If a browser sends a
request for an HTML page, we want to return an XForm embedded in HTML,
but if the browser doesn't want HTML, then we send the "raw" XML record.

If the browser accepts HTML, then it receives an XForm, and the XForm
itself then issues a request (to the same URL!) to retrieve the XML
instance. The problem is that XSLTForms doesn't specify an HTTP Accept
header, and the browser (Firefox 5 for example) sends its default Accept
header, which includes "text/html", etc. Hence the instance document
retrieved is not the "raw" XML representation, but rather an XForm (i.e.
the XForm has loaded itself as a model instance!)

I think it's a bug for XSLTForms to say that it accepts
"text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" (which
is the default Accept header in Firefox). It seems sensible to me to set
an Accept header listing "text/xml" and "application/xml", so that
XSLTForms can be used with services such as ours, which use content
negotiation.

I found I could fix the problem by explicitly setting the Accept header
in xsltforms.js, in two places (there is a case for Internet Explorer
and a case for other browsers). See below:

> if (window.XMLHttpRequest) {
>         Core.openRequest = function(method, uri, async) {
>                 //
> netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead");
>                 var req = new XMLHttpRequest();
>                 try {
>                         req.open(method, Core.constructURI(uri), async);
>                 } catch (e) {
>                         try {
>                                  req = new
> ActiveXObject("Msxml2.XMLHTTP.3.0");
>                            } catch (e) {
>                                 try {
>                                          req = new
> ActiveXObject("Msxml2.XMLHTTP");
>                                 } catch (e) {
>                                            throw new Error("This
> browser does not support XHRs(Ajax)! \n Cause: " + (e.message ||
> e.description || e) + " \n Enable Javascript or ActiveX controls (on
> IE) or lower security restrictions.");
>                                 }
>                         }
>                         req.open(method, Core.constructURI(uri), async);
>                 }
>                 // Added by con...@ve... so xsltforms
> doesn't accept "text/html" (so that HTTP content negotiation can be used)
>                 req.setRequestHeader("Accept",
> "text/xml;q=0.5,application/xml;q=0.6,application/xhtml+xml;q=0.4");
>                 if (Core.isMozilla) {
>                         req.overrideMimeType("text/xml");
>                    }
>                 return req;
>         };
> } else if (window.ActiveXObject) {
>         Core.openRequest = function(method, uri, async) {
>                 try {
>                         req = new ActiveXObject("Msxml2.XMLHTTP.3.0");
>                 } catch (e) {
>                         try {
>                                 req = new ActiveXObject("Msxml2.XMLHTTP");
>                         } catch (e) {
>                                 throw new Error("This browser does not
> support XHRs(Ajax)! \n Cause: " + (e.message || e.description || e) +
> " \n Enable Javascript or ActiveX controls (on IE) or lower security
> restrictions.");
>                         }
>                 }
>                 req.open(method, Core.constructURI(uri), async);
>                 // Added by con...@ve... so xsltforms
> doesn't accept "text/html" (so that HTTP content negotiation can be used)
>                 req.setRequestHeader("Accept",
> "text/xml;q=0.5,application/xml;q=0.6,application/xhtml+xml;q=0.4");
>                 return req;
>         };
> } else {
>         throw new Error("This browser does not support XHRs(Ajax)! \n
> Enable Javascript or ActiveX controls (on IE) or lower security
> restrictions.");
> }
--
Conal Tuohy
eResearch Business Analyst
Victorian eResearch Strategic Initiative
+61-466324297


------------------------------------------------------------------------------
10 Tips for Better Web Security
Learn 10 ways to better secure your business today. Topics covered include:
Web security, SSL, hacker attacks & Denial of Service (DoS), private keys,
security Microsoft Exchange, secure Instant Messaging, and much more.
http://www.accelacomm.com/jaw/sfnl/114/51426210/
_______________________________________________
Xsltforms-support mailing list
Xsl...@li...
https://lists.sourceforge.net/lists/listinfo/xsltforms-support

Re: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types

[Conal C. T. <con...@ve...>]

The other list I mentioned is this one: http://discussions.blackmesatech.com/listinfo.cgi/xforms-blackmesatech.com

"This discussion list hosts general discussions of XForms, both theoretical and practical. Particular emphasis is placed on questions of how best to use XForms to achieve particular ends and how to solve problems with XForms.

Discussions that are focused on the current work of the W3C Forms working group should take place on www...@li..., and discussions that are specific to the behaviors of particular XForms processors should take place on product-specific mailing lists. But general product-independent discussions of how to do specific things with XForms and general debugging questions are in order."
________________________________________
From: Philip Fennell [Phi...@ma...]
Sent: Saturday, 23 July 2011 1:43 AM
To: Conal Christopher Tuohy; xsl...@li...
Subject: RE: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types

Conal,

> I wonder if the new xforms-users list is a more appropriate form

Can you be more specific about the xforms-users list. I've done a quick search but found nothing matching that name.


> I don't really see that it's relevant whether the XHTML+XForms document
> includes an editable XML instance by inclusion or by URI reference.

Taken in isolation, I can also see that, as part of the transformation that generates a resource's representation, it is a moot point as to whether the resource is included in-line in an XForm or, by reference, out-of-line.

I will post a question to the www...@w3... e-mail list to start a discussion about this notion of whether an XForm is a representation of or an application for a resource.


Regards

Philip


-----Original Message-----
From: Conal Christopher Tuohy [mailto:con...@ve...]
Sent: Friday, July 22, 2011 2:08 PM
To: Philip Fennell; xsl...@li...
Subject: RE: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types

Hi Philip

It would be nice if XSLTForms had a complete implementation of XForms 1.1, and if I could use the xf:header feature it would solve my problem, but I think for a 1.0 implementation it does still make sense not to accept a content-type of "text/html" or "*/*" or in general anything other than XML. Unless XSLTForms provides an explicit Accept header when loading an instance, it may accidentally pass on the browser's default Accept header, and for resources which support content negotiation, that not ideal.

On the theoretical point; I think it's an interesting point, but personally do tend to think that an XForm editor for a resource is a perfectly good "representation" of that resource. I don't really see that it's relevant whether the XHTML+XForms document includes an editable XML instance by inclusion or by URI reference. I see it as analogous to a situation where you might get a representation of an image using an Accept header of "image/*" and retrieve e.g. a PNG file, or get a representation with Accept: text/html and retrieve a web page containing a reference to that same PNG representation. I agree that from a theoretical point of view the HTML XForm should not be seen as an HTML representation of an "XML resource". In the web architecture the "resource" itself is something abstract (it's information about a person or information, in this case), and the XML instance is just a representation of that resource. The XForm is also a representation of that same abstract information resource: it's a two-tiered representation in that it transcludes another representation (a RIF-CS XML record), but that pattern is not unusual on the web, actually.

I'm keen to continue discussing the web-architecture aspect of this, though ... I wonder if the new xforms-users list is a more appropriate form, since it's not really specific to XSLTForms.

Regards

Con

________________________________________
From: Philip Fennell [Phi...@ma...]
Sent: Friday, 22 July 2011 7:12 PM
To: Conal Christopher Tuohy; xsl...@li...
Subject: RE: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types

Conal,

Firstly, to my knowledge, the xf:submission element's xf:header element is not currently supported by XSLTForms. This would be the way to specify the Accept header for your requests, but, more importantly, there is a refinement to the use of the xf:header element that affects how they are set by the client. The 'combine' attribute is created to deal with the situation where you want to either add or override the existing header sent by the client. In your case, you would have to use combine="replace" to ensure only the requested content-type is sent. The other options are 'append' and 'prepend' so that you can define how your value is added to an existing header.

Secondly, and I know this might sound a bit nit-picky but, from the way I tend to look at things, I would regard an XForm application and the instance data it loads as two separate resources. The XForm is not an HTML representation of the XML instance data resource it loads. Also, for XSLTForms, the response has to be application/xml in order that the browser will act upon the xml-stylesheet processing instruction. Now, the server is not bound to honour the request's Accept header, it can give either the best it can or say 'Not Acceptable' so just because it asks for HTML doesn't mean it will receive it.

A document, transformed into an HTML Form, that contains the data from the document might be regarded as a text/html representation of that data, but I'm not convinced that you can argue the same for an XForm document that references the document.

I think there is potential ambiguity in the design that you are using which could lead people to say that it is not truly RESTful.

Some people suggest using a type attribute on the Accept header value to extend its meaning. For example, an Atom Feed has a content type of application/atom+xml where as a single Atom Entry is application/atom+xml;type=entry

Maybe, you could use a content type of application/xml;type=edit. This might be a more flexible solution as it would still give you the possibility of requesting an HTML representation that wasn't editable.

I'd be interested in your thoughts on this as it is potentially a common problem with developing for XForms.


Regards

Philip




-----Original Message-----
From: Conal Tuohy [mailto:con...@ve...]
Sent: Friday, July 22, 2011 7:08 AM
To: xsl...@li...
Subject: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types

I have been using XSLTForms recently, for editing XML metadata records.

In our project, we have a RESTful web service (based on a Fedora
repository) which uses HTTP Content Negotiation to publish different
representations of a resource (i.e. using the same HTTP URL, but in
response to different HTTP Accept headers).

Each resource may be represented as an XML metadata record or as an
XForm, depending on the content-type requested. If a browser sends a
request for an HTML page, we want to return an XForm embedded in HTML,
but if the browser doesn't want HTML, then we send the "raw" XML record.

If the browser accepts HTML, then it receives an XForm, and the XForm
itself then issues a request (to the same URL!) to retrieve the XML
instance. The problem is that XSLTForms doesn't specify an HTTP Accept
header, and the browser (Firefox 5 for example) sends its default Accept
header, which includes "text/html", etc. Hence the instance document
retrieved is not the "raw" XML representation, but rather an XForm (i.e.
the XForm has loaded itself as a model instance!)

I think it's a bug for XSLTForms to say that it accepts
"text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" (which
is the default Accept header in Firefox). It seems sensible to me to set
an Accept header listing "text/xml" and "application/xml", so that
XSLTForms can be used with services such as ours, which use content
negotiation.

I found I could fix the problem by explicitly setting the Accept header
in xsltforms.js, in two places (there is a case for Internet Explorer
and a case for other browsers). See below:

> if (window.XMLHttpRequest) {
>         Core.openRequest = function(method, uri, async) {
>                 //
> netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead");
>                 var req = new XMLHttpRequest();
>                 try {
>                         req.open(method, Core.constructURI(uri), async);
>                 } catch (e) {
>                         try {
>                                  req = new
> ActiveXObject("Msxml2.XMLHTTP.3.0");
>                            } catch (e) {
>                                 try {
>                                          req = new
> ActiveXObject("Msxml2.XMLHTTP");
>                                 } catch (e) {
>                                            throw new Error("This
> browser does not support XHRs(Ajax)! \n Cause: " + (e.message ||
> e.description || e) + " \n Enable Javascript or ActiveX controls (on
> IE) or lower security restrictions.");
>                                 }
>                         }
>                         req.open(method, Core.constructURI(uri), async);
>                 }
>                 // Added by con...@ve... so xsltforms
> doesn't accept "text/html" (so that HTTP content negotiation can be used)
>                 req.setRequestHeader("Accept",
> "text/xml;q=0.5,application/xml;q=0.6,application/xhtml+xml;q=0.4");
>                 if (Core.isMozilla) {
>                         req.overrideMimeType("text/xml");
>                    }
>                 return req;
>         };
> } else if (window.ActiveXObject) {
>         Core.openRequest = function(method, uri, async) {
>                 try {
>                         req = new ActiveXObject("Msxml2.XMLHTTP.3.0");
>                 } catch (e) {
>                         try {
>                                 req = new ActiveXObject("Msxml2.XMLHTTP");
>                         } catch (e) {
>                                 throw new Error("This browser does not
> support XHRs(Ajax)! \n Cause: " + (e.message || e.description || e) +
> " \n Enable Javascript or ActiveX controls (on IE) or lower security
> restrictions.");
>                         }
>                 }
>                 req.open(method, Core.constructURI(uri), async);
>                 // Added by con...@ve... so xsltforms
> doesn't accept "text/html" (so that HTTP content negotiation can be used)
>                 req.setRequestHeader("Accept",
> "text/xml;q=0.5,application/xml;q=0.6,application/xhtml+xml;q=0.4");
>                 return req;
>         };
> } else {
>         throw new Error("This browser does not support XHRs(Ajax)! \n
> Enable Javascript or ActiveX controls (on IE) or lower security
> restrictions.");
> }
--
Conal Tuohy
eResearch Business Analyst
Victorian eResearch Strategic Initiative
+61-466324297


------------------------------------------------------------------------------
10 Tips for Better Web Security
Learn 10 ways to better secure your business today. Topics covered include:
Web security, SSL, hacker attacks & Denial of Service (DoS), private keys,
security Microsoft Exchange, secure Instant Messaging, and much more.
http://www.accelacomm.com/jaw/sfnl/114/51426210/
_______________________________________________
Xsltforms-support mailing list
Xsl...@li...
https://lists.sourceforge.net/lists/listinfo/xsltforms-support

Re: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types

[Philip F. <Phi...@ma...>]

Conal,

> I wonder if the new xforms-users list is a more appropriate form

Can you be more specific about the xforms-users list. I've done a quick search but found nothing matching that name.


> I don't really see that it's relevant whether the XHTML+XForms document 
> includes an editable XML instance by inclusion or by URI reference.

Taken in isolation, I can also see that, as part of the transformation that generates a resource's representation, it is a moot point as to whether the resource is included in-line in an XForm or, by reference, out-of-line.

I will post a question to the www...@w3... e-mail list to start a discussion about this notion of whether an XForm is a representation of or an application for a resource.


Regards

Philip


-----Original Message-----
From: Conal Christopher Tuohy [mailto:con...@ve...] 
Sent: Friday, July 22, 2011 2:08 PM
To: Philip Fennell; xsl...@li...
Subject: RE: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types

Hi Philip

It would be nice if XSLTForms had a complete implementation of XForms 1.1, and if I could use the xf:header feature it would solve my problem, but I think for a 1.0 implementation it does still make sense not to accept a content-type of "text/html" or "*/*" or in general anything other than XML. Unless XSLTForms provides an explicit Accept header when loading an instance, it may accidentally pass on the browser's default Accept header, and for resources which support content negotiation, that not ideal. 

On the theoretical point; I think it's an interesting point, but personally do tend to think that an XForm editor for a resource is a perfectly good "representation" of that resource. I don't really see that it's relevant whether the XHTML+XForms document includes an editable XML instance by inclusion or by URI reference. I see it as analogous to a situation where you might get a representation of an image using an Accept header of "image/*" and retrieve e.g. a PNG file, or get a representation with Accept: text/html and retrieve a web page containing a reference to that same PNG representation. I agree that from a theoretical point of view the HTML XForm should not be seen as an HTML representation of an "XML resource". In the web architecture the "resource" itself is something abstract (it's information about a person or information, in this case), and the XML instance is just a representation of that resource. The XForm is also a representation of that same abstract information resource: it's a two-tiered representation in that it transcludes another representation (a RIF-CS XML record), but that pattern is not unusual on the web, actually.

I'm keen to continue discussing the web-architecture aspect of this, though ... I wonder if the new xforms-users list is a more appropriate form, since it's not really specific to XSLTForms.

Regards

Con

________________________________________
From: Philip Fennell [Phi...@ma...]
Sent: Friday, 22 July 2011 7:12 PM
To: Conal Christopher Tuohy; xsl...@li...
Subject: RE: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types

Conal,

Firstly, to my knowledge, the xf:submission element's xf:header element is not currently supported by XSLTForms. This would be the way to specify the Accept header for your requests, but, more importantly, there is a refinement to the use of the xf:header element that affects how they are set by the client. The 'combine' attribute is created to deal with the situation where you want to either add or override the existing header sent by the client. In your case, you would have to use combine="replace" to ensure only the requested content-type is sent. The other options are 'append' and 'prepend' so that you can define how your value is added to an existing header.

Secondly, and I know this might sound a bit nit-picky but, from the way I tend to look at things, I would regard an XForm application and the instance data it loads as two separate resources. The XForm is not an HTML representation of the XML instance data resource it loads. Also, for XSLTForms, the response has to be application/xml in order that the browser will act upon the xml-stylesheet processing instruction. Now, the server is not bound to honour the request's Accept header, it can give either the best it can or say 'Not Acceptable' so just because it asks for HTML doesn't mean it will receive it.

A document, transformed into an HTML Form, that contains the data from the document might be regarded as a text/html representation of that data, but I'm not convinced that you can argue the same for an XForm document that references the document.

I think there is potential ambiguity in the design that you are using which could lead people to say that it is not truly RESTful.

Some people suggest using a type attribute on the Accept header value to extend its meaning. For example, an Atom Feed has a content type of application/atom+xml where as a single Atom Entry is application/atom+xml;type=entry

Maybe, you could use a content type of application/xml;type=edit. This might be a more flexible solution as it would still give you the possibility of requesting an HTML representation that wasn't editable.

I'd be interested in your thoughts on this as it is potentially a common problem with developing for XForms.


Regards

Philip




-----Original Message-----
From: Conal Tuohy [mailto:con...@ve...]
Sent: Friday, July 22, 2011 7:08 AM
To: xsl...@li...
Subject: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types

I have been using XSLTForms recently, for editing XML metadata records.

In our project, we have a RESTful web service (based on a Fedora
repository) which uses HTTP Content Negotiation to publish different
representations of a resource (i.e. using the same HTTP URL, but in
response to different HTTP Accept headers).

Each resource may be represented as an XML metadata record or as an
XForm, depending on the content-type requested. If a browser sends a
request for an HTML page, we want to return an XForm embedded in HTML,
but if the browser doesn't want HTML, then we send the "raw" XML record.

If the browser accepts HTML, then it receives an XForm, and the XForm
itself then issues a request (to the same URL!) to retrieve the XML
instance. The problem is that XSLTForms doesn't specify an HTTP Accept
header, and the browser (Firefox 5 for example) sends its default Accept
header, which includes "text/html", etc. Hence the instance document
retrieved is not the "raw" XML representation, but rather an XForm (i.e.
the XForm has loaded itself as a model instance!)

I think it's a bug for XSLTForms to say that it accepts
"text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" (which
is the default Accept header in Firefox). It seems sensible to me to set
an Accept header listing "text/xml" and "application/xml", so that
XSLTForms can be used with services such as ours, which use content
negotiation.

I found I could fix the problem by explicitly setting the Accept header
in xsltforms.js, in two places (there is a case for Internet Explorer
and a case for other browsers). See below:

> if (window.XMLHttpRequest) {
>         Core.openRequest = function(method, uri, async) {
>                 //
> netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead");
>                 var req = new XMLHttpRequest();
>                 try {
>                         req.open(method, Core.constructURI(uri), async);
>                 } catch (e) {
>                         try {
>                                  req = new
> ActiveXObject("Msxml2.XMLHTTP.3.0");
>                            } catch (e) {
>                                 try {
>                                          req = new
> ActiveXObject("Msxml2.XMLHTTP");
>                                 } catch (e) {
>                                            throw new Error("This
> browser does not support XHRs(Ajax)! \n Cause: " + (e.message ||
> e.description || e) + " \n Enable Javascript or ActiveX controls (on
> IE) or lower security restrictions.");
>                                 }
>                         }
>                         req.open(method, Core.constructURI(uri), async);
>                 }
>                 // Added by con...@ve... so xsltforms
> doesn't accept "text/html" (so that HTTP content negotiation can be used)
>                 req.setRequestHeader("Accept",
> "text/xml;q=0.5,application/xml;q=0.6,application/xhtml+xml;q=0.4");
>                 if (Core.isMozilla) {
>                         req.overrideMimeType("text/xml");
>                    }
>                 return req;
>         };
> } else if (window.ActiveXObject) {
>         Core.openRequest = function(method, uri, async) {
>                 try {
>                         req = new ActiveXObject("Msxml2.XMLHTTP.3.0");
>                 } catch (e) {
>                         try {
>                                 req = new ActiveXObject("Msxml2.XMLHTTP");
>                         } catch (e) {
>                                 throw new Error("This browser does not
> support XHRs(Ajax)! \n Cause: " + (e.message || e.description || e) +
> " \n Enable Javascript or ActiveX controls (on IE) or lower security
> restrictions.");
>                         }
>                 }
>                 req.open(method, Core.constructURI(uri), async);
>                 // Added by con...@ve... so xsltforms
> doesn't accept "text/html" (so that HTTP content negotiation can be used)
>                 req.setRequestHeader("Accept",
> "text/xml;q=0.5,application/xml;q=0.6,application/xhtml+xml;q=0.4");
>                 return req;
>         };
> } else {
>         throw new Error("This browser does not support XHRs(Ajax)! \n
> Enable Javascript or ActiveX controls (on IE) or lower security
> restrictions.");
> }
--
Conal Tuohy
eResearch Business Analyst
Victorian eResearch Strategic Initiative
+61-466324297


------------------------------------------------------------------------------
10 Tips for Better Web Security
Learn 10 ways to better secure your business today. Topics covered include:
Web security, SSL, hacker attacks & Denial of Service (DoS), private keys,
security Microsoft Exchange, secure Instant Messaging, and much more.
http://www.accelacomm.com/jaw/sfnl/114/51426210/
_______________________________________________
Xsltforms-support mailing list
Xsl...@li...
https://lists.sourceforge.net/lists/listinfo/xsltforms-support

Re: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types

[Conal C. T. <con...@ve...>]

Thanks Alain - that's great!

But xf:header is only applicable to xf:submission isn't it? i.e. I can't control the headers of a xf:instance? Though I suppose I could start with an empty xf:instance, and use an xf:submission (with an Accept xf:header) to initialise the instance when the form loads.

Con

________________________________________
From: Alain Couthures [ala...@ag...]
Sent: Friday, 22 July 2011 11:23 PM
To: Conal Christopher Tuohy
Cc: Philip Fennell; xsl...@li...
Subject: Re: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types

Hi Conal,

xf:header is actually implemented in Beta 3 already. So you better give
it a try!

Thank you for your feedbacks!

-Alain

Le 22/07/2011 15:07, Conal Christopher Tuohy a écrit :
> Hi Philip
>
> It would be nice if XSLTForms had a complete implementation of XForms 1.1, and if I could use the xf:header feature it would solve my problem, but I think for a 1.0 implementation it does still make sense not to accept a content-type of "text/html" or "*/*" or in general anything other than XML. Unless XSLTForms provides an explicit Accept header when loading an instance, it may accidentally pass on the browser's default Accept header, and for resources which support content negotiation, that not ideal.
>
> On the theoretical point; I think it's an interesting point, but personally do tend to think that an XForm editor for a resource is a perfectly good "representation" of that resource. I don't really see that it's relevant whether the XHTML+XForms document includes an editable XML instance by inclusion or by URI reference. I see it as analogous to a situation where you might get a representation of an image using an Accept header of "image/*" and retrieve e.g. a PNG file, or get a representation with Accept: text/html and retrieve a web page containing a reference to that same PNG representation. I agree that from a theoretical point of view the HTML XForm should not be seen as an HTML representation of an "XML resource". In the web architecture the "resource" itself is something abstract (it's information about a person or information, in this case), and the XML instance is just a representation of that resource. The XForm is also a representation of that same abstract information resource: it's a two-tiered representation in that it transcludes another representation (a RIF-CS XML record), but that pattern is not unusual on the web, actually.
>
> I'm keen to continue discussing the web-architecture aspect of this, though ... I wonder if the new xforms-users list is a more appropriate form, since it's not really specific to XSLTForms.
>
> Regards
>
> Con
>
> ________________________________________
> From: Philip Fennell [Phi...@ma...]
> Sent: Friday, 22 July 2011 7:12 PM
> To: Conal Christopher Tuohy; xsl...@li...
> Subject: RE: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types
>
> Conal,
>
> Firstly, to my knowledge, the xf:submission element's xf:header element is not currently supported by XSLTForms. This would be the way to specify the Accept header for your requests, but, more importantly, there is a refinement to the use of the xf:header element that affects how they are set by the client. The 'combine' attribute is created to deal with the situation where you want to either add or override the existing header sent by the client. In your case, you would have to use combine="replace" to ensure only the requested content-type is sent. The other options are 'append' and 'prepend' so that you can define how your value is added to an existing header.
>
> Secondly, and I know this might sound a bit nit-picky but, from the way I tend to look at things, I would regard an XForm application and the instance data it loads as two separate resources. The XForm is not an HTML representation of the XML instance data resource it loads. Also, for XSLTForms, the response has to be application/xml in order that the browser will act upon the xml-stylesheet processing instruction. Now, the server is not bound to honour the request's Accept header, it can give either the best it can or say 'Not Acceptable' so just because it asks for HTML doesn't mean it will receive it.
>
> A document, transformed into an HTML Form, that contains the data from the document might be regarded as a text/html representation of that data, but I'm not convinced that you can argue the same for an XForm document that references the document.
>
> I think there is potential ambiguity in the design that you are using which could lead people to say that it is not truly RESTful.
>
> Some people suggest using a type attribute on the Accept header value to extend its meaning. For example, an Atom Feed has a content type of application/atom+xml where as a single Atom Entry is application/atom+xml;type=entry
>
> Maybe, you could use a content type of application/xml;type=edit. This might be a more flexible solution as it would still give you the possibility of requesting an HTML representation that wasn't editable.
>
> I'd be interested in your thoughts on this as it is potentially a common problem with developing for XForms.
>
>
> Regards
>
> Philip
>

Re: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types

[Philip F. <Phi...@ma...>]

Conal,

> Though I suppose I could start with an empty xf:instance, and use 
> an xf:submission (with an Accept xf:header) to initialise the 
> instance when the form loads.

Yes, that's how I tend to do it from the xforms-ready event.

<xf:model>
  <xf:action ev:event="xforms-ready">
    <xf:send submission="submission-id"/>
  </xf:action>
  
  ...

</xf:model>



Regards

Philip

-----Original Message-----
From: Conal Christopher Tuohy [mailto:con...@ve...] 
Sent: Friday, July 22, 2011 2:56 PM
To: Alain Couthures
Cc: Philip Fennell; xsl...@li...
Subject: RE: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types

Thanks Alain - that's great!

But xf:header is only applicable to xf:submission isn't it? i.e. I can't control the headers of a xf:instance? Though I suppose I could start with an empty xf:instance, and use an xf:submission (with an Accept xf:header) to initialise the instance when the form loads.

Con

________________________________________
From: Alain Couthures [ala...@ag...]
Sent: Friday, 22 July 2011 11:23 PM
To: Conal Christopher Tuohy
Cc: Philip Fennell; xsl...@li...
Subject: Re: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types

Hi Conal,

xf:header is actually implemented in Beta 3 already. So you better give
it a try!

Thank you for your feedbacks!

-Alain

Le 22/07/2011 15:07, Conal Christopher Tuohy a écrit :
> Hi Philip
>
> It would be nice if XSLTForms had a complete implementation of XForms 1.1, and if I could use the xf:header feature it would solve my problem, but I think for a 1.0 implementation it does still make sense not to accept a content-type of "text/html" or "*/*" or in general anything other than XML. Unless XSLTForms provides an explicit Accept header when loading an instance, it may accidentally pass on the browser's default Accept header, and for resources which support content negotiation, that not ideal.
>
> On the theoretical point; I think it's an interesting point, but personally do tend to think that an XForm editor for a resource is a perfectly good "representation" of that resource. I don't really see that it's relevant whether the XHTML+XForms document includes an editable XML instance by inclusion or by URI reference. I see it as analogous to a situation where you might get a representation of an image using an Accept header of "image/*" and retrieve e.g. a PNG file, or get a representation with Accept: text/html and retrieve a web page containing a reference to that same PNG representation. I agree that from a theoretical point of view the HTML XForm should not be seen as an HTML representation of an "XML resource". In the web architecture the "resource" itself is something abstract (it's information about a person or information, in this case), and the XML instance is just a representation of that resource. The XForm is also a representation of that same abstract information resource: it's a two-tiered representation in that it transcludes another representation (a RIF-CS XML record), but that pattern is not unusual on the web, actually.
>
> I'm keen to continue discussing the web-architecture aspect of this, though ... I wonder if the new xforms-users list is a more appropriate form, since it's not really specific to XSLTForms.
>
> Regards
>
> Con
>
> ________________________________________
> From: Philip Fennell [Phi...@ma...]
> Sent: Friday, 22 July 2011 7:12 PM
> To: Conal Christopher Tuohy; xsl...@li...
> Subject: RE: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types
>
> Conal,
>
> Firstly, to my knowledge, the xf:submission element's xf:header element is not currently supported by XSLTForms. This would be the way to specify the Accept header for your requests, but, more importantly, there is a refinement to the use of the xf:header element that affects how they are set by the client. The 'combine' attribute is created to deal with the situation where you want to either add or override the existing header sent by the client. In your case, you would have to use combine="replace" to ensure only the requested content-type is sent. The other options are 'append' and 'prepend' so that you can define how your value is added to an existing header.
>
> Secondly, and I know this might sound a bit nit-picky but, from the way I tend to look at things, I would regard an XForm application and the instance data it loads as two separate resources. The XForm is not an HTML representation of the XML instance data resource it loads. Also, for XSLTForms, the response has to be application/xml in order that the browser will act upon the xml-stylesheet processing instruction. Now, the server is not bound to honour the request's Accept header, it can give either the best it can or say 'Not Acceptable' so just because it asks for HTML doesn't mean it will receive it.
>
> A document, transformed into an HTML Form, that contains the data from the document might be regarded as a text/html representation of that data, but I'm not convinced that you can argue the same for an XForm document that references the document.
>
> I think there is potential ambiguity in the design that you are using which could lead people to say that it is not truly RESTful.
>
> Some people suggest using a type attribute on the Accept header value to extend its meaning. For example, an Atom Feed has a content type of application/atom+xml where as a single Atom Entry is application/atom+xml;type=entry
>
> Maybe, you could use a content type of application/xml;type=edit. This might be a more flexible solution as it would still give you the possibility of requesting an HTML representation that wasn't editable.
>
> I'd be interested in your thoughts on this as it is potentially a common problem with developing for XForms.
>
>
> Regards
>
> Philip
>

Re: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types

[Philip F. <Phi...@ma...>]

Efraim,

> The combine attribute, which can have the values "prepend", 
> "append", and "replace", does nothing.

Ahh, may be that is what I remember as not working.

Thanks for clarifying that.


Regards

Philip


-----Original Message-----
From: Efraim Feinstein [mailto:efr...@gm...] 
Sent: Friday, July 22, 2011 2:32 PM
To: xsl...@li...
Subject: Re: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types

Hi,

On 07/22/2011 09:07 AM, Conal Christopher Tuohy wrote:
> Hi Philip
>
> It would be nice if XSLTForms had a complete implementation of XForms 1.1, and if I could use the xf:header feature it would solve my problem, but I think for a 1.0 implementation it does still make sense not to accept a content-type of

Am I missing something? XSLTForms does support xf:header in trunk.

There does seem to be a bug in the implementation, though. Where the 
same header already exists, the XForms spec says that the value should 
be appended to the end. XSLTForms instead prepends it. The combine 
attribute, which can have the values "prepend", "append", and "replace", 
does nothing.


-- 
---
Efraim Feinstein
Lead Developer
Open Siddur Project
http://opensiddur.net
http://wiki.jewishliturgy.org


------------------------------------------------------------------------------
10 Tips for Better Web Security
Learn 10 ways to better secure your business today. Topics covered include:
Web security, SSL, hacker attacks & Denial of Service (DoS), private keys,
security Microsoft Exchange, secure Instant Messaging, and much more.
http://www.accelacomm.com/jaw/sfnl/114/51426210/
_______________________________________________
Xsltforms-support mailing list
Xsl...@li...
https://lists.sourceforge.net/lists/listinfo/xsltforms-support

Re: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types

[Alain C. <ala...@ag...>]

Hi Conal,

xf:header is actually implemented in Beta 3 already. So you better give 
it a try!

Thank you for your feedbacks!

-Alain

Le 22/07/2011 15:07, Conal Christopher Tuohy a écrit :
> Hi Philip
>
> It would be nice if XSLTForms had a complete implementation of XForms 1.1, and if I could use the xf:header feature it would solve my problem, but I think for a 1.0 implementation it does still make sense not to accept a content-type of "text/html" or "*/*" or in general anything other than XML. Unless XSLTForms provides an explicit Accept header when loading an instance, it may accidentally pass on the browser's default Accept header, and for resources which support content negotiation, that not ideal.
>
> On the theoretical point; I think it's an interesting point, but personally do tend to think that an XForm editor for a resource is a perfectly good "representation" of that resource. I don't really see that it's relevant whether the XHTML+XForms document includes an editable XML instance by inclusion or by URI reference. I see it as analogous to a situation where you might get a representation of an image using an Accept header of "image/*" and retrieve e.g. a PNG file, or get a representation with Accept: text/html and retrieve a web page containing a reference to that same PNG representation. I agree that from a theoretical point of view the HTML XForm should not be seen as an HTML representation of an "XML resource". In the web architecture the "resource" itself is something abstract (it's information about a person or information, in this case), and the XML instance is just a representation of that resource. The XForm is also a representation of that same abstract information resource: it's a two-tiered representation in that it transcludes another representation (a RIF-CS XML record), but that pattern is not unusual on the web, actually.
>
> I'm keen to continue discussing the web-architecture aspect of this, though ... I wonder if the new xforms-users list is a more appropriate form, since it's not really specific to XSLTForms.
>
> Regards
>
> Con
>
> ________________________________________
> From: Philip Fennell [Phi...@ma...]
> Sent: Friday, 22 July 2011 7:12 PM
> To: Conal Christopher Tuohy; xsl...@li...
> Subject: RE: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types
>
> Conal,
>
> Firstly, to my knowledge, the xf:submission element's xf:header element is not currently supported by XSLTForms. This would be the way to specify the Accept header for your requests, but, more importantly, there is a refinement to the use of the xf:header element that affects how they are set by the client. The 'combine' attribute is created to deal with the situation where you want to either add or override the existing header sent by the client. In your case, you would have to use combine="replace" to ensure only the requested content-type is sent. The other options are 'append' and 'prepend' so that you can define how your value is added to an existing header.
>
> Secondly, and I know this might sound a bit nit-picky but, from the way I tend to look at things, I would regard an XForm application and the instance data it loads as two separate resources. The XForm is not an HTML representation of the XML instance data resource it loads. Also, for XSLTForms, the response has to be application/xml in order that the browser will act upon the xml-stylesheet processing instruction. Now, the server is not bound to honour the request's Accept header, it can give either the best it can or say 'Not Acceptable' so just because it asks for HTML doesn't mean it will receive it.
>
> A document, transformed into an HTML Form, that contains the data from the document might be regarded as a text/html representation of that data, but I'm not convinced that you can argue the same for an XForm document that references the document.
>
> I think there is potential ambiguity in the design that you are using which could lead people to say that it is not truly RESTful.
>
> Some people suggest using a type attribute on the Accept header value to extend its meaning. For example, an Atom Feed has a content type of application/atom+xml where as a single Atom Entry is application/atom+xml;type=entry
>
> Maybe, you could use a content type of application/xml;type=edit. This might be a more flexible solution as it would still give you the possibility of requesting an HTML representation that wasn't editable.
>
> I'd be interested in your thoughts on this as it is potentially a common problem with developing for XForms.
>
>
> Regards
>
> Philip
>

Re: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types

[Efraim F. <efr...@gm...>]

Hi,

On 07/22/2011 09:07 AM, Conal Christopher Tuohy wrote:
> Hi Philip
>
> It would be nice if XSLTForms had a complete implementation of XForms 1.1, and if I could use the xf:header feature it would solve my problem, but I think for a 1.0 implementation it does still make sense not to accept a content-type of

Am I missing something? XSLTForms does support xf:header in trunk.

There does seem to be a bug in the implementation, though. Where the 
same header already exists, the XForms spec says that the value should 
be appended to the end. XSLTForms instead prepends it. The combine 
attribute, which can have the values "prepend", "append", and "replace", 
does nothing.


-- 
---
Efraim Feinstein
Lead Developer
Open Siddur Project
http://opensiddur.net
http://wiki.jewishliturgy.org

Re: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types

[Philip F. <Phi...@ma...>]

Alain,

> xf:header is actually implemented in Beta 3 already.

Really, wow, I'll have to try that out, thanks!


Regards

Philip

-----Original Message-----
From: Alain Couthures [mailto:ala...@ag...] 
Sent: Friday, July 22, 2011 2:24 PM
To: Conal Christopher Tuohy
Cc: Philip Fennell; xsl...@li...
Subject: Re: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types

Hi Conal,

xf:header is actually implemented in Beta 3 already. So you better give 
it a try!

Thank you for your feedbacks!

-Alain

Le 22/07/2011 15:07, Conal Christopher Tuohy a écrit :
> Hi Philip
>
> It would be nice if XSLTForms had a complete implementation of XForms 1.1, and if I could use the xf:header feature it would solve my problem, but I think for a 1.0 implementation it does still make sense not to accept a content-type of "text/html" or "*/*" or in general anything other than XML. Unless XSLTForms provides an explicit Accept header when loading an instance, it may accidentally pass on the browser's default Accept header, and for resources which support content negotiation, that not ideal.
>
> On the theoretical point; I think it's an interesting point, but personally do tend to think that an XForm editor for a resource is a perfectly good "representation" of that resource. I don't really see that it's relevant whether the XHTML+XForms document includes an editable XML instance by inclusion or by URI reference. I see it as analogous to a situation where you might get a representation of an image using an Accept header of "image/*" and retrieve e.g. a PNG file, or get a representation with Accept: text/html and retrieve a web page containing a reference to that same PNG representation. I agree that from a theoretical point of view the HTML XForm should not be seen as an HTML representation of an "XML resource". In the web architecture the "resource" itself is something abstract (it's information about a person or information, in this case), and the XML instance is just a representation of that resource. The XForm is also a representation of that same abstract information resource: it's a two-tiered representation in that it transcludes another representation (a RIF-CS XML record), but that pattern is not unusual on the web, actually.
>
> I'm keen to continue discussing the web-architecture aspect of this, though ... I wonder if the new xforms-users list is a more appropriate form, since it's not really specific to XSLTForms.
>
> Regards
>
> Con
>
> ________________________________________
> From: Philip Fennell [Phi...@ma...]
> Sent: Friday, 22 July 2011 7:12 PM
> To: Conal Christopher Tuohy; xsl...@li...
> Subject: RE: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types
>
> Conal,
>
> Firstly, to my knowledge, the xf:submission element's xf:header element is not currently supported by XSLTForms. This would be the way to specify the Accept header for your requests, but, more importantly, there is a refinement to the use of the xf:header element that affects how they are set by the client. The 'combine' attribute is created to deal with the situation where you want to either add or override the existing header sent by the client. In your case, you would have to use combine="replace" to ensure only the requested content-type is sent. The other options are 'append' and 'prepend' so that you can define how your value is added to an existing header.
>
> Secondly, and I know this might sound a bit nit-picky but, from the way I tend to look at things, I would regard an XForm application and the instance data it loads as two separate resources. The XForm is not an HTML representation of the XML instance data resource it loads. Also, for XSLTForms, the response has to be application/xml in order that the browser will act upon the xml-stylesheet processing instruction. Now, the server is not bound to honour the request's Accept header, it can give either the best it can or say 'Not Acceptable' so just because it asks for HTML doesn't mean it will receive it.
>
> A document, transformed into an HTML Form, that contains the data from the document might be regarded as a text/html representation of that data, but I'm not convinced that you can argue the same for an XForm document that references the document.
>
> I think there is potential ambiguity in the design that you are using which could lead people to say that it is not truly RESTful.
>
> Some people suggest using a type attribute on the Accept header value to extend its meaning. For example, an Atom Feed has a content type of application/atom+xml where as a single Atom Entry is application/atom+xml;type=entry
>
> Maybe, you could use a content type of application/xml;type=edit. This might be a more flexible solution as it would still give you the possibility of requesting an HTML representation that wasn't editable.
>
> I'd be interested in your thoughts on this as it is potentially a common problem with developing for XForms.
>
>
> Regards
>
> Philip
>