484   Clarification on P element restrictions

Created: 20 Mar 2007

Status: Not Applicable

Part: Part 6 (2004)


Page: 70

Clause: 9.4.3

Paragraph: 5

Category: No impact on this part


Clause 9.4.3 paragraph 5 seems to suggest that if one leaves out the type restriction (e.g. xsi:type=tP_IP), anything could be entered into a *predefined* P element type and the SCL file would still be considered valid. For example, <P type="IP">abc</P> is implied to be valid but this is not a valid IP address.

There are already cases of ICD files from multiple vendors that have invalid P element content (e.g. APPID and VLAN-ID with incorrect number of characters, not matching the restrictions imposed by IEC 61850-8-1 Table 112), but still being valid XML because the type restriction is not present.

From clause 9.4.3
The advantage of the second, which uses the restriction type of tP, is that the address value
(here ? can also be validated by an XML parser. Using the first formulation, an
address value of ?abc? would be considered as perfectly valid, while the second formulation
expects a value of the form ?ddd.ddd.ddd.ddd?, where each d corresponds to a digit.


Suggest adding a sentence that even though the type restriction can be left out, the content of a predefined P element type must still meet the restrictions imposed by the SCSM.

Discussion Created Status
The format of addresses is introduced in the normative part of 8-1, and is therefore normative. There are a lot of normative things, which can either not be expressed by schema constraints, or even not in part 6 (e.g. allowed LN classes / CDCs). In this special case, the rules are contained in the 8-1 normative part, and therefore are normative. I see no sense in writing additionally for a normative part, that it should be followed.... Further, stating that 'it can be checked by the supplied syntax elements', in my opinion implicitely contains that the rules must be followed in any case. 21 Mar 07 Not Applicable


Privacy | Contact | Disclaimer

Tissue DB v.