Re: Do we want to bring p:data back?

As a teacher, having a p:data for binary only, and a p:document for xml 
sounds good to me. It is simple to explain.

But, we should be able to parse a binary data if it is XML that has been 
loaded in binary. Is p:cast-content-type can be used for this ?

<p:cast-content-type content-type="xml">
   <p:input port="source">
     <p:data href="foe.xml"/>
   </p:input>
</p:cast-content-type>

It doesn't seem to me.

Maybe an optional input port on p:load...

Best,
Christophe


Le 07/09/2017 à 15:48, Norman Walsh a écrit :
> Hi all,
>
> When we moved towards supporting non-XML documents natively, we
> decided that p:data wasn’t necessary anymore. The idea being that
> p:document could load XML or non-XML documents.
>
> I wonder if that’s true. If we can determine the media type from the
> filename, I suppose we could use that, but that raises two problems:
> what if the media type is unknown and what if the author knows they
> want to load a .bin file as XML?
>
> In other words, what does this mean:
>
>    <p:document href="pipe.xpl"/>
>
> Do we try to load that as XML and fall back to non-XML if the parse
> fails? What if it’s supposed to be XML and is not well-formed?
>
> I begin to suspect that p:data is actually useful for authors. It
> allows them to express “load this as binary” while p:document allows
> them to express “load this as XML”.
>
> We could keep a single element and allow them to make this distinction
> with an attribute (a content-type attribute, for example), or document
> properties:
>
>    <p:document href="pipe.xpl"
>                document-properties="{ map {{ 'content-type': 'image/png' }} }”/>
>
> but that’s a lot more typing.
>
>                                          Be seeing you,
>                                            norm
>
> P.S. Separate email coming in a moment about the awkwardness of that
> document-properties AVT.
>

Received on Friday, 8 September 2017 11:05:30 UTC