Liam and all,
I think this thread of discussion has been a interesting topic. And
here's my 2 cents.
I think for XML to evolve, to define an extended and standardized
XDM (beyond what's current supported by XML syntax) can be an
important and winning strategy. It's already mentioned and hinted
several time in this thread already:
Decoupling XDM from XML syntax has several advantages:
- The DM is no longer constrained by the XML syntax. It can
evolve to cover wider range of data, like JSON, CSV, MIME
Message, file system nodes, zip archive nodes, etc. Among all,
the most important is to unify with object data model, like JSON
(and JavaFX literal object).
- XML vendors who have invested heavily to implement XML
Schema/XSLT/XQuery, would also benefit from the extended DM, as
their products can now support more data formats. The cost of
implementing new data parsers/adapters is relatively cheap. This
is like the .Net architecture, with one runtime supporting
multiple languages.
- People has the freedom to choice their syntax or serialization
format. Whether it is JSON, HTML5, XML or YAML, it no longer
matters. What's important is the DM now. People who still
depends on legacy XML features (like doctype), like MathML, can
live in the old XML world. People who wants better formats can
go for XML2.0 or XML5 or XML.next, without the burden of
backward syntax compatibility.
- It can also be an opportunity to clean up the mess in current
W3C XML DM related standards, as defined in InfoSet, XML Schema,
XPath/XQuery DM, etc. A cleaned up DM would help streamline the
integration of XML technologies.
Some of the important features of the extended XDM should include:
- Clean up the data types, throw away the doctype related types.
- Allow child node to contain data types other than text.
- Allow attribute node to contain complex content. This is
important in unifying with object data model (JSON map can
contain nest map).
- No need to require root element.
The language, Candle (http://www.candlescript.org/), that I've
created, is along this line. Some of the relevant documents are:
Regards
Henry
On 3/1/2012 11:04 PM, BillClare3@aol.com
wrote:
786e.6d9ec56b.3c3472ec@aol.com" type="cite">
Liam,
Two thoughts on an interesting topic that could address
the fundamentals of XML evolution.
Something to add: Full data type
specifications with properties, constraints, associations and
event driven methods. This can move much of behavior
specification and implementation out of the agent. With this,
by the way, schema, as currently constructed, specify
constructors for data types, not the data types themselves.
Something to remove: Distinctions between
element attributes and contents.
Bill
In a message
dated 1/2/2012 1:06:16 P.M. Eastern Standard Time, liam@w3.org writes:
On Mon, 2012-01-02 at
10:27 -0500, David Lee wrote:
> What's missing ?
David, thanks for replying!
> 1) A Standard (or well adopted convention) for
Serialized XDM so that
> programs may exchange XDM in addition to XML
I think (Rich Salz notwithstanding) EXI 2 may do
this. Remains to be
seen, but I hope so.
> 2) Better support for XDM in XQuery and XSLT to
allow the input 'document'
> to be any XDM value, and corresponding support
in the implementations to
> portably read such data (see #1)
I'm not sure on the status of this; the first part
is already there I
think, unless you're asking for a further relaxing
of constraints in the
XDM - in which case please file a comment against
the last call draft of
the XDM 3.0 that was published in December; the
Status section of the
document has a link to the Bugzilla instance for
doing that.
As for implementations - can you think of ways we
could test it? if so,
feel free to contribute tests, or to join the WG :-)
or just to bug the
vendors.
>
> 3) Adoption of the JSON Data model into XDM so
that XPath/XSLT/XQuery/Schema
> can be directly used on JSON data
Agreed.
>
> 4) A standard/convention for JSON / XDM
conversions to allow #1 as both
> input and output.
Not sure if this is premature, but it may fall under
your No, 3 above.
> 5) "Excel for XML" (or XDM see #1) so prevalent
and accepted that it becomes
> acceptable to pass XML among business partners
instead of having to convert
> to/from CSV or XLS.
Well, that would be nice. It'd have to offer a
business advantage - one
or more of
. faster
. lower cost
. enabling (things you couldn't do before)
Thanks for the feedback!
Liam
--
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
_______________________________________________________________________
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
|
