[
Lists Home |
Date Index |
Thread Index
]
>> 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. In fact, an "XHTML to explicit XLink" XSLT
>> stylesheet should be pretty trivial, especially if all you want is to
>> build tools which harvest the links.
>
> One of our issues, which has been previously asserted here, is that we
> want to be as processable by a "pure-play" XML browser as any other XML
> vocabulary (yes, we'll be provided a default style sheet people can
> adopt, etc).
>
> Anything that then requires arcane knowledge is not going to be warmly
> embraced as an acceptable solution.
so what about defining an xlink data model in terms of infoset
extensions, referencing it in xhtml and defining an xhtml-happy syntax
for it, and then going ahead and defining a css3 module for link
formatting? i don't see any problems with that approach, apart from the
fact that there would be a lot of work to do (for example, also persuade
the xpath 2.0 folks that they need to provide generic support for
infoset extensions and not only the core infoset plus psvi).
css3 would require some work, because the selectors would need to be
extended to cover infoset extensions, and a new module for properly
handling link formatting would be required. however, i think it would be
worth it, since this could be used for *any* vocabulary being built on
the xlink data model.
i think this would be the clean and extensible way to go, even in terms
of "pure-play" xml, as ann has put it.
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. *
|
