Re: [svgwg] Building a schema for SVG / Creating an SVG profile for IEC 61850-6-2 (#699)

My comments on the SVG aspects of the draft specification (IEC 61850, Part 6-2: Configuration description language for extensions for human machine interfaces, as posted as an attachment [above](https://github.com/w3c/svgwg/issues/699#issuecomment-628598916))…

## p11 

> a. SVG 2 has been adopted as the basis for GCL. It should be noted that at time of circulation SVG 2 is only a W3C editors draft, and it is not an official Candidate Recommendation. We expect an evolution of SVG 2 to become a Candidate Recommendation by the time of IEC 61850-6-2 publication.

SVG 2 _has_ been published as a [Candidate Recommendation](https://www.w3.org/TR/SVG2/), but that is not a stable/final document in the W3C process. [A candidate recommendation indicates](https://www.w3.org/2019/Process-20190301/#candidate-rec) that the WG thinks the spec covers the requirements for standardization, and that they are inviting implementations to proceed, with implementers expected to give feedback on it. In our case, given the complexity of the spec, implementer feedback has so far resulted in considerable edits, and more edits are expected. Because of the ongoing edits, we do encourage people to consult the latest Editor's Draft, but the official spec status at W3C is CR.

## p16

> 1.4 SVG Namespace
> The parameters which are identifying this new release of the XML namespace `xmlns:svg=" http://www.iec.ch/61850/202X/SVG"`

I would _strongly_ advise against defining a new XML namespace with the `svg` prefix. To the extent that you are re-using SVG elements and attributes, please define them in the SVG namespace (`http://www.w3.org/2000/svg`, which is invariable across SVG specification levels). Later sections of the document (e.g., p34) correctly reference this namespace URI.

Using the correct namespace is essential for those graphics to be correctly rendered by existing SVG software, e.g., in a web browser or an embedded web view in an application.  The mapping of element types (namespace + tag name) to DOM interfaces and their implicit rendering model cannot be specified by document authors; it is hard-coded in the rendering engine.

To the extent that you want to define additional attributes or elements (the GCL SVG extensions), create a unique namespace with a prefix that is unlikely to be confused with the established SVG namespace prefix.

## p30

Figure 6 implies that the full SVG specification is contained within the definition of GCL. But the text later says

> GCL mandates a minimum subset of the SVG and our requirements only call for a basic SVG profile. Additional SVG functionalities are optional, and the SVG profile defined within are the minimum requirements.

Now, interpretation of figures is not usually normative & maybe it would be confusing to distinguish required and optional bits within the diagram, but I thought I'd mention that it confused me a bit.

## p34

I think the spec nicely summarizes the concept of an SVG Profile as an application-specific subset of the full SVG specification.

> The W3C does not currently support an SVG schema, however there are future aspirations to develop a schema.

Maybe more accurate to say “however, the SVG working group has indicated that they would be willing to adopt or endorse a schema if it is useful to multiple implementers”.

## p35

> The scope of the GCL namespace is limited to the SVG profile and applicable extensions

This sentence confuses me. What does it mean for another namespace to be “scoped” to a subset of the SVG spec?

Perhaps what you mean is that GCL namespace defines elements and attributes that are scoped within SVG document fragments within the larger document?

## p43

It might be worth clarifying that the “Element” objects in your data model are not the same thing as XML elements (or rather, they are a specific type of XML element). Alternatively, consider a different name, e.g., “Component” (if that doesn't already have a specific meaning in your data model).

## p44

I think the custom-namespaced elements described here (for declaratively setting, the SVG style/text changes for different application states) is a good example of an extension to SVG that can be implemented with a scripting layer on top of an existing SVG renderer.

You might want to consider matching the capitalization conventions of SVG in element naming (first letter always lowercased, subsequent words capitalized). Although, further extensions to SVG itself will be harmonized with HTML (all lowercased, even for compound words), so consistency may be overrated!

## p46

Not SVG related, but: You may wish to convert your `desc` from an attribute to a child element, so that it could be extended in future to support markup including language annotations and bidirectional information.  See the [W3C internationalization checklist for developing specifications](https://www.w3.org/International/techniques/developing-specs).

Similarly, for your string formatters (e.g., p58) and dynamic string labels, you might want to consider how you could extend your syntax to support different formatters for different language environments.

## p49

I don't understand what the “logical node namespace” is and how it complements or interacts with XML namespaces in the document. Is it possible to use a different name without this confusion (e.g., “scope” instead of “namespace”)?

## p60−61

> A value conforming to SVG’s basic type <color> for the specific color to be referred to by this Color definition. The value must be on the list of recognized color keyword names included in the SVG specification, or a numerical RGB specification.

> A value conforming to SVG’s basic type <length> to be used for the specific stroke width referred to by this StrokeWidth definition. The syntax must be as required by the SVG specification for SVG the stroke-width presentation attribute.

I assume these sections were written when you were still using SVG 1.1 as your reference. SVG 2 doesn't define either `<color>` or `<length>` data types, instead incorporating the CSS definitions by reference to the [CSS Values specification](https://www.w3.org/TR/css-values/).

Since the current CSS definitions of these types are rather complex, you probably want to explicitly list which syntaxes are supported.

## p63

The extension to `<use>` elements seems well designed. By using a new attribute to cross link to the GCL `<Element>` you want to instantiate, you leave it possible for applications to insert the correct `href` directly to the SVG fragment that needs to be rendered.

## p70−77

The draft seems to be missing content here. Let me know if this was accidental.

## p78−100 (The SVG Profile)

Note that the breakdown of the SVG spec into chapters is not guaranteed stable. There has been considerable re-organizing since SVG 1.1.

For support for attributes, you should indicate in the context of which elements. E.g., it doesn't make much sense to say that support for the `x` attribute is required without specifying on which element: there are many `x` attributes in SVG!

Note that refX/refY on `<symbol>` elements is new in SVG 2 and not well supported.

Similarly, the `inline-size`, `shape-inside`/`shape-padding`, and `text-overflow`/`text-align` style properties on SVG text content elements are not well implemented.

These seems to be the only poorly-supported feature you have marked as mandatory.  Although not officially marked at risk yet, they may still be removed from the SVG 2 spec prior to it reaching recommendation status. 

I didn't review the use cases sections carefully; a quick search didn't find any references to SVG in that part of the draft.








-- 
GitHub Notification of comment by AmeliaBR
Please view or discuss this issue at https://github.com/w3c/svgwg/issues/699#issuecomment-632946707 using your GitHub account

Received on Friday, 22 May 2020 23:51:44 UTC