Try two as the first one seems to have gone into a bit bucket.
--Alex Milowski
Forwarded message 1
Alessandro Vernet wrote:
>
> Alex,
>
> My comments about the proposed standard component library:
>
> On 11/9/06, Alex Milowski <alex@milowski.org> wrote:
>> 1.4. [p:]serialize
>>
>> The [p:]serialize component applies XML serialization to the
>> children of the document element and replaces those children
>> with their serialization. The outcome is a single element with
>> text content that represents the "escaped" syntax of the
>> children if they were serialized.
>
> What would be the qname of that root element? In Orbeon Forms (which
> used to be called Orbeon PresentationServer or OPS), the component
> that serves the same purpose as p:serialize is called
> oxf:xml-converter and it generates a root element as follows:
>
> <document xsi:type="xs:string" content-type="application/xml;
> charset=iso-8859-1">
>
> The benefit of indicating the type this way is that you can extend
> this to handle binary data encapsulated in XML (with
> xsi:type="xs:base64Binary"). Then given a <document> another component
> has all the information it needs to say store it in a file on disk or
> sent it in an HTTP response. More on binary documents:
>
> http://www.orbeon.com/ops/doc/reference-formats
>
> Also, we might want to have more parameters on p:serialize. See for
> instance how the equivalent component in Orbeon Forms can be
> configured:
>
> http://www.orbeon.com/ops/doc/processors-converters#d12e74
I'm not sure if this is the same component. The serialize component
produces escaped XML for applications that need that.
For example, the input might be an RSS description element with some
XHTML in it:
<description>
<div xmlns="http://www.w3.org/1999/xhtml">
<p>This resource is...</p>
</div>
</description>
and the output is:
<descrioption>
<div xmlns="http://www.w3.org/1999/xhtml">
<p>This resource is...</p>
</div>
</description>
This root element is the document element. In the case of producing
an RSS feed, you'd use a viewport to limit the [p:]serialize step
to the 'description' elements.
>
>> 1.5. [p:]parse
>>
>> [...]
>>
>> When the text value is parsed, a document element wrapper should be
>> assumed so that element siblings can be parsed back into XML.
>
> Do we need this wrapper element? Are the use cases that call for a
> wrapper element frequent enough that we are willing to pay the cost of
> the added complexity here? To me, adding a wrapper element looks
> orthogonal to parsing.
Yes. In some cases--like the RSS description element--the contents
contains more than one element. If you parsed that data as XML, you'd
get an error. Wrapping the contents allows you to parse this as XML.
>
>> 2.1. [p:]xquery
>>
>> The [p:]xquery component applies a query to a collection and
>> provides the result of the query as its output.
>
> How is the XQuery expression come in the 'input' document?
Some queries can be represented by single XML elements. But to do
this for every XQuery, we'll need an input wrapper element that the
component understands. That could also be a place to put
query controls.
>> 2.3. [p:]validate
>
> Should this component be called p:xml-schema-validate, if it performs
> only validation with XML Schema? Or is your intention to extend the
> component later to allow for other schema languages such as Relax NG
> to be used?
Possibly. I had the idea that we'd allow one validate component to
understand multiple schema languages.
>
>> 2.5. [p:]url-action
>
> This is incredibly useful, but I am afraid that we are opening a can
> worms by trying to specify this now. Also note that this is somewhat
> similar to the XForms's <xforms:submission>. I would prefer not to
> include this component for now. If we think that the use cases calling
> for this component are too important for us to ignore this, I would
> try to reuse the XForms submission.
I would really, really like to include this component. I use it all
the time to interact with web services that require posts. We may
also want it to help with the GRDDL folks.
Of course, we don't *have* to have every kind of component we can
dream up as standard. I just think interacting with URLs is a basic
feature of the web.
>
> The submission element in XForms 1.0:
> http://www.w3.org/TR/xforms/slice3.html#structure-model-submission
>
> Additions in XForms 1.1 (working draft):
> http://www.w3.org/TR/xforms11/#submit
Thanks. I will take a look.
--Alex Milowski