>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.
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
|
