[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] Serialization of XDM
- From: "David A. Lee" <dlee@calldei.com>
- To: Mukul Gandhi <gandhi.mukul@gmail.com>
- Date: Mon, 14 Sep 2009 15:25:09 -0400
There is one other use case submitted to me privately:
Paraphrased:
5) given a huge xml instance, in an XML database or flat file.
Basically too big to manage with XSLT.
Use xquery to extract manageable chunks, then pass on to XSLT to
process as required.
Reconstitute the results back to an XML document.
David A. Lee
dlee@calldei.com
http://www.calldei.com
http://www.xmlsh.org
812-482-5224
David A. Lee wrote:
> Here are some use cases I am imagining. They may well lead to
> different ideal representations ...
>
> 1) Program to Program interop
> XDM producer program produces a set of values to be used by an XDM
> consumer
>
> Example: XQuery produces a sequence of nodes to be passed into an
> XSLT or XQuery external variable in a different environment.
>
> 2) Internal XML Program Interop
> "Orchestrating" or "Scripting" programs that want to expose their
> connectivity in a standard way.
>
> Example: XProc "pipes" are a subset of XDM, (sequence of Documents).
> This includes the input and output of the processor as a whole.
> It would be nice if XProc implementations would accept a standard
> representation for both input and output, as well as expose a standard
> implementation for interconnectivity between steps. This would allow
> XProc engines to interop with different vendor's step definitions
> independently of the implementation of the engine. It would also
> allow a standard for supplying data to XProc and outputting data from
> XProc (sequence of nodes).
>
> Example: A vendor's XQuery accepts XDM values as declared external
> variables. There is no standard on how these may be passed into XQuery.
> An XDM Serialization standard would allow standards on how to say
> supply a file containing XDM values to any XQuery implementation.
>
> 3) XML to NON-XML Program interop
> If an XML program (say XQuery) outputs XDM data which is to be
> consumed by a NON-XML program (say a program that reads text or CSV),
> it would be very nice if there was a standard format to produce, or
> atleast a standard way to convert such a format.
> This is a similar but distinct case from #4
>
>
> 4) Standard "User Friendly" output of XDM processes
> Current xquery and xpath implementations vary on how they output XDM
> values (such as non-documents).
> Example. What is a standard output of '1 to 10' ?
> It would be very useful if vendors could agree on at least one
> standard for this. Typical examples I've seen are space separated, or
> newline separated output.
>
>
>
>
>
>
>
> David A. Lee
> dlee@calldei.com http://www.calldei.com
> http://www.xmlsh.org
> 812-482-5224
>
>
>
> Mukul Gandhi wrote:
>> Hello David,
>> I think, I agree with you, that it's a good idea to be able to
>> serialize an XDM instance into some form. I would prefer an XML format
>> for the serialized XDM instance. i.e, perhaps we could define a XML
>> Schema for XDM serialization format.
>>
>> But I am keen to know, what could be useful use cases, for XDM
>> serialization? I can think of interoperability of XDM instances
>> between vendros, as on the use cases for XDM serialization. But would
>> this really give some/any value to users (say query[XQuery] and
>> stylesheet[XSLT] writers)?
>>
>> It seems to me, XDM serialization is like aiming to go to mars at this
>> point of time :)
>>
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]