OpenSAML user discussion

["Scott Cantor" <>]

> I'm not going to discuss that here. First of all because I'm not the
> one who's able to discuss such kind of things, and secondly because
> that's the specification of eduGAIN and I don't know the reasons to
> use that XPath instead the one that OpenSAML is using.

You misunderstand my comment. The schema is what it is. I don't know what
XPath has to do with this, but my point was that OpenSAML simply tries to
let you put stuff into Advice in accordance with the schema. It shouldn't be
in conflict with whatever you're doing, but if it is, I wanted to understand
why.

But adding to the DOM directly is definitely not supported in general. I'm
sorry if that's a problem for you, but that is the reason you encountered an
issue.

> I can't use getAdvice(), because, as I said, we are setting Advices
> manually, and of course we need to retrieve them manually. If I use
> getAdvice(), then our advices would be have to be stored at //
> Assertion/Advice/AssertionIDReference/, which conflicts with our specs
> (see above).

That's the schema. I don't understand what you're doing that "conflicts"
with that but somehow is legal. I'm sure it's possible, but I'm simply
trying to understand your problem so I can suggest the best work-around.

I'm simply asking if this assumption about having to do it all manually is a
misunderstanding.

> What's the supported approach, then?

The only support is the set/getAdvice methods. If that's not good enough,
there isn't any supported mechanism, and that means you'll have problems
that have to be worked around.

The reason the Advice support is very limited is that Advice is not
something I had a requirement for.

> Yes, but you have to still retrieve the owner document to get an
> element on which to call getElementByTagNameNS(). Otherwise, you'll
> have to assume that casting the Node returned by toDOM() to an Element
> object will work...

And you can assume that, because that's guaranteed by the method. Sorry if
that's not clear. The reason it returns a Node is mostly historical I think.
I don't know that I even recall why it wasn't typed as an Element.

In any case, you do not need to get the owner document except to create DOM
nodes yourself, which is not supported. But if you do it, using
toDOM().getOwnerDocument() is ok for that because the SAML object doesn't
need to be rooted for that to work.

> opinion. And it's very poor because when you call toDOM() on an
> object, from the user's point of view, you expect to get the DOM for
> that object, with the document rooted adequately and all the contents
> of the object inside, perfectly mapped and rendered as they are in the
> object itself.

And I don't agree. I think it means you get a DOM. Rooting it in a document
was not a requirement I had, and is not something I expect. Mainly because
what you're asking would break any attempt to add that object in DOM form to
some other DOM tree, because appendChild breaks if the object already has a
parent node. I had that requirement and that's why the code works that way.
It also breaks the recursive use of the method to build up the DOM in the
first place.

> More in detail, that means that a user will expect that
> a call to toDOM() will call inside that "plantRoot()" method, just as
> toString() or signing methods do, just because the user expects the
> complete object *always*, not only when printing to a string.

You get a complete object. You don't get a complete *document*. That is what
*this* user expected and needed. Since the code was written for me, that
kind of drives the process.

> As I've said, then, in my opinion, the interface offered by OpenSAML
> is very poor, as you don't have a clear idea of what you get when
> calling a method and what is worse, things does not work as you would
> expect them to do.

Not having a clear idea is a failure of documentation, not code. Since the
code is virtually undocumented, that isn't a big surprise, but I have always
been up front with people about that.

> It's exactly the same use case as signing and
> validating signatures on an OpenSAML object. You can't sign() and then
> inmediately validate an object, which is absolutely crazy.

You can't do that in most libraries. Try it with xmlsec alone. It fails
miserably.

> I'm not discussing the
> reasons that made OpenSAML behave like that, but my complain is about
> the interface given to the user. You can't assume that a user will be
> calling toString() just after toDOM().

And I don't. Look, try to think about this for two seconds. What happens if
you call toDOM on a nested object like a statement or a condition? Would you
expect that to suddenly become the document element? Why? What happens to
the assertion it was wrapped in?

I don't think you're grasping the larger context of this problem. But since
I doubt we're going to agree on this, I'll point out a more relevant issue:
the code is NOT changing. It's been replaced already.

What exactly are you asking me to do?
 
-- Scott