Hi Frank,
thanks for taking the time to review this!
Frank Schönheit - Sun Microsystems Germany wrote:
Hi Michael,
so i would be especially interested in input from people who would
like to use ODF metadata: does this API do what you need?
I don't know :), but have some other feedback (always "IMO")
- Pair< T, U > clearly belongs into css.beans
(yes, that's nasty, since you need to add udkapi to your CWS then :)
ok.
- css.rdf is perfectly okay for the types - I wouldn't put them below
another module, finally, the interfaces can probably be used for other
purposes later.
ok. (i thought maybe we already have too many top-level modules...)
- Re: "FIXME: hmmm, does it make sense to allow creating arbitrary blank
nodes?"
Not sure about "blank" here. Mozilla's API, which I used some year
ago, has something like "createAnonymousNode", IIRC (My memory
might *completely* fool me here). If that's a same as a "blank" node,
then I think such a thing might be useful - at least I used anonymous
nodes in my only encounter with RDF so far.
hmm, the question was more like do we have a create() that can only
generate fresh and unique blank nodes, or create(String nodeid), which
would allow creating arbitrary blank nodes, even ones that already exist
in the repository (with potentially unintended aliasing effects).
but since we can hardly implement "fresh and unique blank nodes" in a
_service constructor_ that does not know any actual repository, the point
seems kind of moot.
or we introduce a factory at the repository just to be able to create
"fresh and unique blank nodes"...
- Re "FIXME: would a base RDFException make sense?"
I tend to answering "no" here, since transforming the question would
be "Are there use cases where a client would be interested in catching
the RDFException only, without evaluating the actual derived
exception?" Since *all* information in all the RDF*Exceptions is in
their type, and not in their members, I suppose there are no such use
cases.
ok.
- RDF*Exception;
If they all are in the namespace css.rdf, then the RDF in the name
might be considered superfluous. For instance, the
RDFRepositoryException could better be a
css.rdf.(Illegal)RepositoryException, and the like.
ok.
- XRDFRepository::importGraph:
I'd suggest throwing a WrappedTargetException here, instead of the
IOException. IMO (but that might be only me) this better separates
errors in the stream usage (i.e. an externally-supplied component)
from "internal" errors, and errors in the arguments.
Similar for other methods of this interface.
hmm, good point. i had mistakenly assumed that the X*Stream methods throw
only IOException, but they actually throw 3 different exceptions.
err, wait a minute, on closer examination it seems that IOException is a
common supertype of all 3 exception types...
in _that_ case, i would argue that since X*Stream is a published, stable
interface, wrapping a WrappedTargetException around the IOExceptions
introduces an unnecessary indirection and obfuscation.
Ciao
Frank
mfg,
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
