That's a big bunch of factories... It was more that the naming seemed upside down - one would normally expect SomethingImpl to implement/extend Something - not the other way around :)
So I think I get it - the distinction from IRIFactoryImpl and its superclass AbsIRIFactoryImpl is that IRI only subclass the Abs* one - as it does not do any of the conformance and validation bits done by the IRIFactoryImpl/IRIFactory. What is the difference between IRIFactory and IRIFactoryImpl then? There's implementation in both. Is it the package name? Then there's the other confusing hierarchy - but at least here the IRIImpl extends IRI. AbsIRIFactoryImpl -> IRI (abstract) -> AbsIRIImpl -> IRIImpl So if IRI is abstract, why is there then an additional abstract AbsIRIImpl? Or in other words - why isn't IRI an interface (extending IRIFactoryI) instead of a class, and then let AbsIRIImpl be a subclass of AbsIRIFactoryImpl? Apologies with these silly questions.. I think I won't try to do the .toURI() (and create(URI) ) patch given the confusion of all these - but perhaps Martynas want to have a go? On 8 January 2015 at 14:01, Andy Seaborne <[email protected]> wrote: > On 08/01/15 13:50, Stian Soiland-Reyes wrote: >> >> BTW.. why is there this confusing class hierarchy? >> >> IRIFactory extends IRIFactoryImpl extends AbsIRIFactoryImpl implements >> IRIFactoryI > > > I don't understand the question and probably don't know the answer anyway. > > And it's not what I see. > > abstract public class IRI > extends AbsIRIFactoryImpl > implements IRIFactoryI, IRIRelativize > > public class IRIFactory > extends IRIFactoryImpl > implements IRIFactoryI > > > IRIs are "self factories" - given one, you can make another with "construct" > and "create" (IRI resolution occurs). > > The final "I" in IRIFactoryI is "Interface" -- an old style naming. > > Andy > > >> >> >> >> On 8 January 2015 at 13:30, Andy Seaborne <[email protected]> wrote: >>> >>> On 08/01/15 12:57, Martynas Jusevičius wrote: >>>> >>>> >>>> Thanks. >>>> >>>> Couldn't Jena's IRI be made to extend java.net.URI, override the >>>> methods that differ, and still be accepted where URI is expected? >>> >>> >>> >>> java.net.URI is a final class. >>> >>> Probably other issues as well (IRIs are unicode, URIs are ASCII ; RFC >>> 2396 >>> vs 3896) but that's a blocker in itself. >>> >>> IRIs are not particularly cheap - the resolver has caching to mitigate >>> this. >>> >>> The parsing rules such as the scheme-specific stuff (that IRI adds over >>> j.n.URI) can have a noticeable cost (e.g. parsing). Another cost is the >>> use >>> of regexs - using java.net.URI to parse the structure (it has a >>> hand-written >>> URI parser) might help partly. >>> >>> Slightly bizarrely, if you pass in the components of a java.net.URI, java >>> builds a string and parses it to get the components again. >>> >>> Adding IRI.toURI operation might help c.f. IRI.toURL. Contributions >>> welcome. >>> >>> Andy >>> >>> >>>> >>>> On Tue, Jan 6, 2015 at 10:27 PM, Andy Seaborne <[email protected]> wrote: >>>>> >>>>> >>>>> On 06/01/15 16:22, Martynas Jusevičius wrote: >>>>>> >>>>>> >>>>>> >>>>>> Hey, >>>>>> >>>>>> I'm reading URIs from request input that will end up in an RDF Model. >>>>>> They can be relative, in which case they need to be resolved, and they >>>>>> can be invalid, in which case they need to be rejected. >>>>>> >>>>>> What I'm looking for is to replace new URI/URI.create() and >>>>>> URI.resolve(uri) usages with a more RDF-compliant solution. >>>>>> >>>>>> I wanted to check if IRIResolver is the right class for this purpose? >>>>>> Are there any examples? >>>>> >>>>> >>>>> >>>>> >>>>> org.apache.jena.riot.system.IRIResolver (not the legacy one in the old >>>>> N3 >>>>> parser). >>>>> >>>>> This uses the jena-iri library which is quite, err, "precise". >>>>> >>>>> See also the parsing pipeline that uses CheckerIRI for checking. In >>>>> fact, >>>>> you might want to use StreamRDF (where all parers send things). >>>>> >>>>> Andy >>>>> >>>>>> >>>>>> >>>>>> Thanks. >>>>>> >>>>>> Martynas >>>>>> >>>>> >>> >> >> >> > -- Stian Soiland-Reyes, myGrid team School of Computer Science The University of Manchester http://soiland-reyes.com/stian/work/ http://orcid.org/0000-0001-9842-9718
