Open danyill opened 1 year ago
In the above example, you are speaking about the xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
in the P
element right?
Yes, but it applies to any namespace associated with the imported IED.
On Sat, 30 Sep 2023, 16:51 Jakob Vogelsang, @.***> wrote:
In the above example, you are speaking about the xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance" in the P element right?
— Reply to this email directly, view it on GitHub https://github.com/OpenEnergyTools/scl-lib/issues/54#issuecomment-1741846812, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFEXX5ME6XYHUA6BO6METLX5BZ3HANCNFSM6AAAAAA5MVM2WQ . You are receiving this because you authored the thread.Message ID: @.***>
I am asking because in particular the above-mentioned I have always seen on the element. I think there was something about it that it has too. We should research that.
I am asking because in particular the above-mentioned I have always seen on the element. I think there was something about it that it has too. We should research that.
That would surprise me because it would only be one way of providing a valid reference to the namespace.
I had a look through IEC 61850-6-2 and found that it commonly uses the short prefix:
Here is another example: Archive.zip
I start with test_comms.scd
, I insert the SEL device XAT_SEL-487E-5_StandardDesign.ICD
with the result of test_comms (26).scd
with the result that all namespaces are fully qualified:
<Private type="SEL_IedInfo">
<esel:ModelNumber xmlns:esel="http://www.selinc.com/2006/61850">SEL-487E-5S</esel:ModelNumber>
<esel:ModelVersionMin xmlns:esel="http://www.selinc.com/2006/61850">R404</esel:ModelVersionMin>
<esel:ClassFileVersion xmlns:esel="http://www.selinc.com/2006/61850">007</esel:ClassFileVersion>
<esel:ClassFileDescription xmlns:esel="http://www.selinc.com/2006/61850" default="false">487E-5S - Sampled Values Subscriber R404-V0 or higher (Ed. 2 support, Controllable mod/beh)</esel:ClassFileDescription>
<esel:IcdFilePath xmlns:esel="http://www.selinc.com/2006/61850">C:\XAT_SEL-487E-5_StandardDesign_Production_mod.ICD</esel:IcdFilePath>
</Private>
<Private type="SEL_IedComm">
<esel:MMS xmlns:esel="http://www.selinc.com/2006/61850" inactivityTimeout="900"/>
</Private>
<Private type="SEL_IedResources">
<esel:InDigitals xmlns:esel="http://www.selinc.com/2006/61850">
<esel:InBits format="VB{0:D3}" min="1" max="256"/>
</esel:InDigitals>
<esel:InAnalogs xmlns:esel="http://www.selinc.com/2006/61850">
<esel:InFloat format="RA{0:D3}" min="1" max="256"/>
</esel:InAnalogs>
<esel:GooseRxFilter xmlns:esel="http://www.selinc.com/2006/61850" APPID="true" goCbRef="true" datSetRef="true" goId="true" confRev="true" ndsCom="true" test="true"/>
<esel:GooseTx xmlns:esel="http://www.selinc.com/2006/61850" minMaxTime="4"/>
<esel:GooseTx xmlns:esel="http://www.selinc.com/2006/61850" maxBoolData="512"/>
<esel:SVRx xmlns:esel="http://www.selinc.com/2006/61850" max="7"/>
<esel:SVRxAnalogChannels xmlns:esel="http://www.selinc.com/2006/61850" max="24"/>
<esel:Reports xmlns:esel="http://www.selinc.com/2006/61850" maxDataSetSize="8000"/>
<esel:System xmlns:esel="http://www.selinc.com/2006/61850" mmsAuthenticationSupported="true"/>
<esel:System xmlns:esel="http://www.selinc.com/2006/61850" controllableModeSupported="true"/>
</Private>
Do you have a proposal how to resolve this issue? I feel we had a discussion about this already. @danyill
I think we need a helper function to scan namespaces and add them to the SCL element which is what Part 6 recommends. I can't help wondering if this isn't at some level a "core" function - spot an edit which includes a namespaced element and if it's not already there, add it. Perhaps we need some input from @ca-d?
I think we might add some smart logic to the Edit
API within open-scd-core
to handle these cases. I'm envisaging something like:
Insert
ed Node
has node.ownerDocument === this.doc
, we're done.Update
contains no namespaced attributes, we're done.Update
or in the Insert
ed Node
's DOM tree:
node.ownerDocument.documentElement.lookupPrefix(namespaceURI)
.Update
s that exchange all namespace prefixes for the prefix that's already defined on the root element. We're done.3.i
What do you think about this procedure?
It seems desirable to me. Is it too expensive to recurse through all nodes as a matter of course though? I am thinking especially of Insert and Remove edits.
If that caused a significant performance penalty then having a "don't worry I know what I'm doing" flag might be a good idea.
On Wed, 3 Apr 2024, 01:00 cad, @.***> wrote:
I think we might add some smart logic to the Edit API within open-scd-core to handle these cases. I'm envisaging something like:
- If the Inserted Node has node.ownerDocument === this.doc, we're done.
- If the Update contains no namespaced attributes, we're done.
- For any namespaced attributes in the Update or in the Inserted Node's DOM tree:
- Check if we already have a namespace prefix defined using node.ownerDocument.documentElement.lookupPrefix(namespaceURI) .
- If so, add Updates that exchange all namespace prefixes for the prefix that's already defined on the root element. We're done.
- Else, add the first prefix that's found to the root element, go back to step 3.i
What do you think about this procedure?
— Reply to this email directly, view it on GitHub https://github.com/OpenEnergyTools/scl-lib/issues/54#issuecomment-2031855291, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFEXX536KTLWD3XICKU5P3Y3KMXDAVCNFSM6AAAAAA5MVM2WSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZRHA2TKMRZGE . You are receiving this because you were mentioned.Message ID: @.***>
In the above procedure, we would recurse through all nodes only in the case of Insert
actions containing a node
from a foreign document. In the case of Remove
, there's nothing that needs doing, and we assume that in the case of nodes from this.doc
all the relevant namespace prefixes have already been declared on the root element.
Do you think we need to cover more cases than these?
No that seems complete, and even if there is a cost, we must not (not ever) sacrifice correctness for performance...
So yes let's do it!
I should note that we've found at least two ICT tools which don't correctly manage namespaces so I think it's important to handle it and I am especially pleased that core should handle this. It shouldn't be something a plugin author has to worry about and that's what I like about your proposal 😉👍
On Wed, 3 Apr 2024, 22:43 cad, @.***> wrote:
In the above procedure, we would recurse through all nodes only in the case of Insert actions containing a node from a foreign document. In the case of Remove, there's nothing that needs doing, and we assume that in the case of nodes from this.doc all the relevant namespace prefixes have already been declared on the root element.
Do you think we need to cover more cases than these?
— Reply to this email directly, view it on GitHub https://github.com/OpenEnergyTools/scl-lib/issues/54#issuecomment-2034074661, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFEXX2TDFNGGLIMUXRQ6PLY3PFNNAVCNFSM6AAAAAA5MVM2WSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZUGA3TINRWGE . You are receiving this because you were mentioned.Message ID: @.***>
Currently our insertIED doesn't handle namespaces correctly.
Rather than being declared on the document they are "long-hand" against every instance:
For instance:
What I've done previously to resolve this (without using the Edit API) is:
However I think we could use an update edit to do this now.
I think we'd transfer each namespace definition and between the IED being inserted and the SCL document it is being inserted into. I'm not sure but I think setAttributeNS will handle namespace collisions as well.