[
Lists Home |
Date Index |
Thread Index
]
Erik Wilde writes:
> i think what we really need is an upgrade of css selectors, to cover
> generic infoset extensions. this way, css could select the link
> information items and format them.
>
> this is not that far-fetched. if you look at the current xpath 2.0
> data model draft, you will recognize that it is a union of the
> infoset and psvi data. i like that approach, but i think that not
> only psvi support should be hard-wired into the data model, but there
> should be support for additional infoset contributions, which would
> as a result be accessible through xslt and xquery (and dom xpath
> and...). and if these additional contributions are required to map
> properly to xml schema data types, then they can be integrated fairly
> easily into the xpath 2.0 data model.
I'd recommend that you explore the archives on xml-dev and look for
discussion of the Infoset in particular.
You may find that the Infoset isn't as popular a notion as you seem to
find it, and that the only Infoset extensions some people (myself
vocally included) are willing to work with are those which can be
expressed explicitly in XML 1.0.
The proposal in XML Linking and Style [1] defines XLink contributions to
the Infoset, but it does so in terms of Element Information Items,
adding nothing fundamentally new to the Infoset. I'm not sure whether
your proposal and that proposal are similar.
That proposal seems fine to me because of its grounding in XML. I won't
touch an Infoset-only proposal with a thousand-foot pole at this point;
in fact I'd much prefer to see the XML Linking and Style proposal
defined as a transformation that produces one flavor of XML from another
rather than wasting cycles on Information Items.
[1] - http://www.w3.org/TR/xml-link-style/#xlink-infoset
-------------
Simon St.Laurent - SSL is my TLA
http://simonstl.com may be my URI
http://monasticxml.org may be my ascetic URI
urn:oid:1.3.6.1.4.1.6320 is another possibility altogether
|
