krautzource/sre-to-tree

preserve existing IDs

Closed this issue · 9 comments

pkra commented

A node might already have an id (which might be referenced from elsewhere). Do we preserve such IDs?

pkra commented

Do we preserve such IDs?

No, we do not. But we should.

pkra commented

Not sure if SRE is a better place for this - ping @zorkow, what do you think?

SRE should not be overwriting ids. Semantic ids are stored elsewhere, not in the id attribute.
In principle, all the attributes that are in the incoming structure should also be in the enriched structure. Where do you see this?

pkra commented

Thanks @zorkow and apologies for creating confusion.

SRE is not doing anything wrong, sre-to-tree is.

sre-to-tree currently writes over pre-existing IDs with the IDs it generates from data-semantic-id. Stopping that is easy, but now sre-to-tree needs to rewrite the aria-owns properties of their semantic parents.

While I don't think it makes sense for SRE to consider re-using pre-existing ids as data-semantic ids, I thought I'd better double check with you.

pkra commented

While I don't think it makes sense for SRE to consider re-using pre-existing ids as data-semantic ids, I thought I'd better double check with you.

To expand slightly: if SRE re-used pre-existing IDs as data-semantic-id, then the data-semantic-owns would already have the "correct" id so sre-to-tree just had to not overwrite it. But I suspect it's just overhead for SRE without anything to gain from SRE's point of view.

pkra commented

I have a preliminary implementation that needs more testing.

While I don't think it makes sense for SRE to consider re-using pre-existing ids as data-semantic ids, I thought I'd better double check with you.

To expand slightly: if SRE re-used pre-existing IDs as data-semantic-id, then the data-semantic-owns would already have the "correct" id so sre-to-tree just had to not overwrite it. But I suspect it's just overhead for SRE without anything to gain from SRE's point of view.

Not a good idea. The semantic tree is constructed with minimal reference to the incoming structure. Original attributes are preserved via folding the tree back into the original structure. So trying to reuse ids while the tree is constructed is not practical. Also it would conflate concerns.

The only mechanism would be to mark up leaf nodes. The ext-id mechanism we use for MathLive is an example. But in general I think this should be done by the caller.

I have a preliminary implementation that needs more testing.

Is that in master?

pkra commented

The only mechanism would be to mark up leaf nodes. The ext-id mechanism we use for MathLive is an example. But in general I think this should be done by the caller.

Thanks for confirming.

Is that in master?

Not yet.