Cart
[Home] [By Thread] [By Date] [Recent Entries]
Simon St.Laurent <simonstl@s...> replies:
>
> Peter.Hunsberger@s... (Hunsberger, Peter) writes:
> >I'm not sure quite what the issue is? Aren't URIs well
> enough defined
> >that something like:
> >
> > *[concat('#',substring-after(uri,'#')) = @rdf:resource]
> >
> >should behave predictably? Or am I just missing something
> completely?
>
> If I just want to match IDs, I can do something like that,
> and likely will. (Probably combined with Uche's suggestions.)
>
> Fragment identifier interpretation can get far trickier than
> that, though, especially given the possibilities in the
> XPointer Framework.
>
> http://www.w3.org/TR/xptr-framework/
>
> For this case, I can probably stumble through, but there are plenty of
plausible
> (largely hypertextual) cases where XSLT/XPath's lack of
> XPointer understanding will make life difficult. XInclude's dodged
> that bullet, in Section 4.2, but even that supports the element()
scheme.
Umm, did you mean hypothetical?
I was understanding (guessing?) that you didn't have to handle the
generalized case... In the general case, yes, that's a pain: we're up
against the same thing though I think we're going to be able to
restrict/control the fragments and don't have to handle everything.
Having a XSLT processor that supports eval() will likely suffice for us,
though truthfully I haven't spent a whole lot of time thinking about
this yet.
> (At the same time, I really don't want to pile anything additional
into those
> specs. If I could swap out schema support in favor of XPointer
support - well,
> I'd think about that one and probably prefer it.)
You mean as an option for like the entire universe? Ok, I think I'd vote
for that as well ;-)
|
