It can be a winning strategy for everyone. :-)
On 4/1/2012 11:49 AM, Henry Luo wrote:
4F03CC54.4020803@candlescript.org" type="cite">
Decoupling XDM from XML syntax has additional advantages:
- From user perspective, they'll be happy if their effects in
learning XML Schema/XSLT/XQuery/XProc can be extended to do
direct HTTP/SMTP message handling, shell scripting, etc.
- From W3C perspective, the XML standards stack will be more
important and useful then ever.
Regards
Henry
On 4/1/2012 11:34 AM, Henry Luo wrote:
4F03C8D6.8070703@candlescript.org"
type="cite">
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
|
