[
Lists Home |
Date Index |
Thread Index
]
Simon St.Laurent wrote:
> Paul Prescod writes:
>>"Simon St.Laurent" wrote:
>>>That said, I think something like Erik Wilde's proposal of looking
>>>at XLink as an abstraction and permitting the mapping of components
>>>from other vocabularies into that abstraction works well.
>>>Link harvesters shouldn't need a whole lot of training to figure out
>>>that "href==(xlink:href xlink:type='simple') in XHTML." This is a
>>>pretty easy transformation.
>>That solution is fine for a vocabulary as widely deployed as XHTML.
>>But how do I communicate that Docbook's linking elements are "really"
>>XLinks in disguise? Or TEI? Or ...
>>I think that there needs to be a way to make that declaration out of
>>line. Perhaps in something like CSS. Perhaps in the schema. Perhaps in
>>something new altogether.
> Yes, it's yet-another-packaging-problem, and no one wants to go near
> packaging. For now, RDDL seems like a good place to put this
> information, as does a MIME Content-type registration.
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.
cheers,
erik wilde - tel:+41-1-6325132 - fax:+41-1-6321035
mailto:net.dret@dret.net - http://dret.net/
computer engineering and networks laboratory
swiss federal institute of technology (eth)
* try not. do, or do not. there is no try. *
|
