RE: [xml-dev] XSLT, RDF, fragment identifiers

Simon St.Laurent <> replies:

> 
>  (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 ;-)