Klotz, Leigh wrote:
But using @mediatype="text/plain" to suppress the anchor would have the
unwanted effect of not allowing to dereference plain text any more.
JI'm not sure I understand.
Here's what I believe: I believe <xf:output mediatype="text/plain" /> is what
most user agents do today, except for FormsPlayer, which allows something like
xslt:disable-output-escaping and can dereference entities and reparse the output into text/html
or application/xhml+xml.
I believe that if an author writes
<xf:output mediatype="text/plain" ref="homepage" />
Then the authir would expect the output to be
http://www.example.com
I think you see it differently, but I don't understand how. It's quite likely
I'm wrong, but I don't see it.
just
<xf:output ref="homepage"/>
where the homepage node has type anyURI.
The difference is just the missing '@mediatype'.
For your example (again assuming node 'homepage' has type anyURI)
<xf:output mediatype="text/plain" ref="homepage"/>
i would expect the value of node homepage (a URI) to be dereferenced and
inserted/rendered as plain/text. If homepage is just of type 'string'
then of course the behavior would be as known from XForms 1.0.
Joern
Leigh.
-----Original Message-----
From: Joern Turner [mailto:joern.turner-S0/GAf8tV78@xxxxxxxxxxxxxxxx]
Sent: Friday, February 03, 2006 2:37 PM
To: Klotz, Leigh
Cc: Ulrich Nicolas Lissé;
chiba-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
Subject: Re: [Chiba-developer] Proposed changes to Chiba output attribute
extensions to bring them into line with W3C recommendations and drafts
Klotz, Leigh wrote:
Joern,
I don't think the decision about how/whether to suppress the hyperlink should detract from Uli's proposal.
It's just a minor issue. It's a good proposal since it
Agree. I've just put that into my local XSLT and it feels good as a replacement
of the appearance approach.
is clearly legal under XForms 1.0 and doesn't require any XForms 1.1 support.
I suppose you could say that an author would always want hyperlink when xf:output is bound to xsd:anyURI, but it seems worthwile to be able to suppress it.
Anyway, here is a simple example where the goal is to construct a sentence
containing text:
Leigh.
<html xmlns...>
<head>
<title>Test</title>
<xf:model>
<xf:instance><data
xmlns=""><homepage>http://www.example.com</homepage>...</data></xf:instance>
<xf:bind nodeset="homepage" type="xsd:anyURI" />
</xf:model>
</head>
<body>
<h1>Test</h1>
My home page is <xf:output ref="homepage" />.
<body>
</html>
ok, this *is* a possible use-case.
But using @mediatype="text/plain" to suppress the anchor would have the
unwanted effect of not allowing to dereference plain text any more.
Instead it maybe would be an alternative to use the @readonly mip instead. If the
output is bound to a Node of type anyURI and no @mediatype is present and the node
is readonly -> suppress the linking.
Kind of makes some sense to me to consider the readwrite/readonly state of an
anyURI node as being activatable or not.
Joern
-----Original Message-----
From: Joern Turner [mailto:joern.turner-S0/GAf8tV78@xxxxxxxxxxxxxxxx]
Sent: Friday, February 03, 2006 1:46 PM
To: Klotz, Leigh
Cc: Ulrich Nicolas Lissé;
chiba-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
Subject: Re: [Chiba-developer] Proposed changes to Chiba output
attribute extensions to bring them into line with W3C recommendations
and drafts
Klotz, Leigh wrote:
Uli, Interesting. Would you recommend @mediatype="text/plain" for
suppressing the anchor? This seems like a good suggestion to take
back to he WG for Xforms 1.1.
Leigh,
in which situation do you want to suppress the anchor? Don't get it - please
explain.
My simple understanding from Uli is:
- if there's no @mediatype at all and the output is bound to anyURI
show a link
- if there's a @mediatype this takes precedence and in case the output is bound
to an anyURI node this URI is used for dereferencing the actual content.
Joern
The advantage of the xlink declaration is that it is noted in markup
as a hyperlink, which seems at least in the spirit of xlink. But I
understand that the Xlink recommendation leaves more questionst than
answers, and the WG that produced it is gone.
Leigh.
-----Original Message----- From: Ulrich Nicolas Lissé
[mailto:u.n.l-hi6Y0CQ0nG0@xxxxxxxxxxxxxxxx] Sent: Thursday, February 02, 2006 1:30 PM To:
Klotz, Leigh Cc: Joern Turner;
chiba-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
Subject: Re: [Chiba-developer] Proposed changes to Chiba output
attribute extensions to bring them into line with W3C recommendations
and drafts
hello leigh,
thanks a lot for your efforts. i agree with you regarding image
outputs: these should be handled by implementing
output/@mediatype='image/*'. but to go further i propose *not* keep
chiba's @appearance='image' any longer in the xslt (same applies to
@appearance='anchor').
furthermore i fully agree that generating an anchor via
xf:output/@mediatype='text/html' in conjunction with @value or
@calculate resembles bad javascript habits. but i've to confess that
i'm one of the people who find the xlink hack questionable. therefore
i propose the following:
if an xf:output is bound to datatype anyURI (or any restricted type
extension thereof) and no mediatype child/@mediatype attribute is
present, it's rendered as an anchor. that seems to me the simplest
and most portable solution.
actually it seems too easy to me. did i miss something ?
regards, uli.
Klotz, Leigh wrote:
Sorry! It was a cut and paste from the image one, you're right.
But I don't see a way to output hyperlinks using
output/@mediatype='text/html' unless the instance data already
contains a literal <xhtml:a href="">label</xhtml:a>. Any
approach involving generating html from the instance
xf:output/@value or bind/@calculate quickly turns into a document.write kind of hack.
Another possibility is to go to exforms.org and propose
standardizing appearance="exforms:anchor" and
appearance="xforms:image" instead of using the mediatype from Xforms
1.1 WD and the xlink hack, which I understand some find questionable.
Leigh.
-----Original Message----- From: Joern Turner
[mailto:joern.turner-S0/GAf8tV78@xxxxxxxxxxxxxxxx] Sent: Wednesday, February 01, 2006 2:30
PM To: Klotz, Leigh Cc: chiba-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
Subject: Re: [Chiba-developer] Proposed changes to Chiba output
attribute extensions to bring them into line with W3C
recommendations and drafts
Klotz, Leigh wrote: <snip/>
2. Output as anchor The current Chiba provides this necessary
functionality with the non-standard output/@appearance='anchor'.
Extensions to appearance are allowed under XForms 1.0, but they
must be qualified names. So, to be valid Xforms this appearance
attribute value should be output/@appearance='chiba:anchor'. It may
make more sense to implement this function as
output/@mediatype='image/*' from the XForms 1.1 proposal.
Leigh,
think you're meaning output/@mediatype="text/html" here? A typo?
Joern
Implement partial Xlink support on output with
output/@xlink:type='simple' when there is no xlink:href present.
This idea is due to Kenneth Sklander, and is based on the Xlink
recommendation, which lists xlink:type as the only required
attribute.
XLink purists may object that a link without a lexically visible
URI is not discoverable; however, it is at least declared as a
link, and I doubt they would be happy with @appearance="chiba:anchor"
declaring something to be a link.
I have also proposed to Mozilla Xforms that they implement
Kenneth's interpretation of XLink, as their user agent also has
partial XLink support. I don't see any interaction with the XForms
recommendation here, as foreign namespaced attributes are already
allowed, so I believe that this is ready to go.
In html-form-controls.xsl change
<xsl:when test="@xforms:appearance='anchor'"> to <xsl:when
test="@xforms:appearance='anchor' or (@xlink:type='simple' and
not(@xlink:href))">
Leigh L. Klotz, Jr. Xerox Corporation
------------------------------------------------------- This SF.net
email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that
makes searching your log files as easy as surfing the web.
DOWNLOAD
SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642
_______________________________________________ Chiba-developer
mailing list Chiba-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/chiba-developer
------------------------------------------------------- This SF.net
email is sponsored by: Splunk Inc. Do you grep through log files for
problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web.
DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642
_______________________________________________ Chiba-developer
mailing list Chiba-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/chiba-developer
-- Ulrich Nicolas Lissé
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
|
