The LN0 LN class is always LLN0, so no inst attribute is needed. For the referencing of links to LN0, lnInst shall be missing, and lnClass shall be LLN0.
The second sentence should be changed, in my opinion, as it conflicts with the schema definition. Here lnInst is sometimes defined as type=""tLNInst tEmptyLN" and use="required" which reads to me it cannot be missing
- leave this restriction out
- change the schema for name="lnInst" be always use="optional"
- or change to: if referencing to element LN0 lnInst must be empty string and change the schema accordingly
16 Dec 22
Back to the original sentence in part 6:
"For the referencing of links to LN0, lnInst shall be missing, and lnClass shall be LLN0."
This sentence should be confusing in case of reference elements which have lnInst attribute mandatory, as it is in ClientLN. In this case, the lnInst attribute shall be empty for LLN0.
This is why I am proposing following sentence as editorial:
"For the referencing of links to LN0, lnInst shall be missing when attribute is optional or shall be empty when attribute is required, and lnClass shall be LLN0."
This proposal is not adding new behavior to current edition and is fully inline with the current Schema.
28 Nov 22
Changing this from "shall be specified except for LLN0" to "may be specified (as empty string) even if LLN0" could break existing IED tools (ICTs) which assume absence of this attribute when LLN0 is specified.
I agree with 17 Aug 22 comment that no change is needed.
05 Oct 22
open for comment
05 Oct 22
Proposed to make an editorial change and revise the restriction statement to: "For the referencing of links to LN0, lnInst shall be missing or empty when attribute is required, and lnClass shall be LLN0."
05 Oct 22
There is a clear statement in clause 9.3.5 that specifies that LN0 shall always be named LLN0 (See Restiction comment below table 16). Since XSD validation is not enough for SCL validation and this is just another example that SCL validation is require.