-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update Edit API handles namespaced attributes poorly #132
Comments
If I understand correctly an example with more attributes could look like this? updateV2: UpdateV2 = {
element,
attributes: { attrName: 'attrValue' } // non-namespaced attrs only
attributesNS: {
'https://example.org/myNS': {
attrName1: 'attrValue1',
attrName2: 'attrValue2',
},
'https://example.org/userNS': {
name: 'John',
age: '42',
}
}
} probably one object would look weird right? so just one updateV2: UpdateV2 = {
element,
attributes: {
'': { // non-namespaced attrs only
attrName: 'attrValue'
}
'https://example.org/myNS': {
attrName1: 'attrValue1',
attrName2: 'attrValue2',
},
'https://example.org/userNS': {
name: 'John',
age: '42',
}
}
} |
which alternative names have you considered?
|
Yeah empty would look weird I think. I liked |
Oh yes. That makes sense! |
The Update event could use an update, since the current handling of namespaced attribute updates is both cumbersome and - in one edge case - insufficient.
Currently attributes are grouped by (unprefixed) name and attach an extra
namespaceURI
parameter to the value:The cumbersome aspect is that
namespaceURI
is quite long to type.The functionally insufficient aspect is that this disallows setting two different attributes from two different namespaces if they happen to be named the same, e.g. if I wanted to simultaneously set both the
svg:x
attribute and thesxy:x
attribute from the SVG and IEC 61850-6 Annex C.1 namespaces, respectively.I suggest changing this part of the API by separating namespaced from non-namespaced attributes in the update event like so:
resulting in a new type
Since this project is still in alpha, I think the new type could actually replace the current
Update
type without too much trouble, which seems preferable to me. If this does not happen until the first stable version of open-scd-core is released, I would then tend more to adding a newUpdateV2
type in addition to the old one and consequently supporting the deprecated legacy API til kingdom come.The text was updated successfully, but these errors were encountered: