Building a schema for SVG / Creating an SVG profile for IEC 61850-6-2 #699
Comments
|
Thanks for bringing this up, Dustin. As I've suggested to you privately, I think this project has interesting parallels to the SVG Native project being pursued within the group: both seek to create standardized subsets of SVG for specific use cases. But, one size doesn't fit all. I understand that an important requirement for your use case is text handling, which is explicitly excluding for SVG Native, which is aimed at image-only environments (icons and graphics for native apps) and is currently being designed to also replace the restrictions on SVG glyphs in OpenType. All of these subsets are different from the ones created for SVG Tiny and SVG Basic. So I agree that the WG should consider the general problem: how can we make it clear & straightforward to define a new profile / subset of SVG & its conformance require? One question for you Dustin: do you have examples of what you mean by “conformance statements”? For detailed conformance testing, the SVG spec is mostly using the web platform test framework. It's well integrated by the major browsers, but may need better guidelines for how to work with those tests for stand-alone SVG rendering agents. |
|
Thanks Amelia. I agree there are some opportunities for joint-development that will benefit both task forces. Indeed, SVG Native/Basic is too basic for our application, but we will try to define a profile in a manner that maybe you/others could re-use. We face the same challenge in IEC 61850, so we have defined guidelines and rules on how to go about this. (See IEC 61850-1-2 and IEC 61850-7-7). As for the conformance statements, there are three aspects to consider:
Here is an example of a PIXIT: https://selinc.com/api/download/100939/ Here is an example of a MICS: http://testing.ucaiug.org/Testing/Shared%20Documents/Templates/IEC%2061850%20MICS%20Template%20v0.1.doc Here is an example of a SICS:
Hope this helps. Regards, |
|
The SVG Working Group just discussed
The full IRC log of that discussion<AmeliaBR> Topic: SVG Extensions/Subset profiles ( IEC 61850-6-2)<AmeliaBR> github: https://github.com//issues/699 <krit> ScribeNick: krit <krit> AmeliaBR: this issue was brought up be ppl working on a standard within IEC for describing power station interfaces. Representation should be described with the help of SVG. And the group would integreraet this into their standard without the full complexity of SVG. However, the group does want to have text which is not part of SVG Native for instance. SVG tiny doesn't fulfil the requirements either. <krit> AmeliaBR: So the request is to have a way to specify a subset by referencing sections they need. <krit> AmeliaBR: They also ask for an SVG schema that they can include by reference. <krit> AmeliaBR: IMO it is a nice comparison to SVG Native. We also want to define a subset of SVG full. As we go on with SVG Native we should think about subsetting SVG full in a more general term. A process that other ppl can follow <krit> AmeliaBR: We would also need to define how that can be conformant checked with test suites. <krit> sairus: At the OT meeting last week we talked about features that are not even covered by SVG Full like CMYK support. Could SVG Native be the minimum subset for any specification in the future? <krit> chris: Like the idea but the spec currently has not text support which might make it to minimal. <krit> AmeliaBR: Yeah, some ppl need the full functionality of shapes with all its complexity but not interested in colors. <krit> chris: CSS Colors 4 covers CMYK. Happy to talk to you about integration in SVG Native. <krit> sairus: thanks. So is SVG Full too complex in general? <krit> AmeliaBR: There are differences between authoring tool and rendering applications like web browsers. <krit> AmeliaBR: So we would need to define a conformant viewer and the other side around. <krit> sairus: IMO OT handles it very well with its tables. Implementations just support some table but not the others. Defining tables in OT is organically. <krit> AmeliaBR: OT has the table structure that allows list out the tables which an implementation supports or does not support. SVG has elements, attributes and style properties which all interact. <krit> sairus: OT has kind of similar issues and it can get complex too. But we handle it organically in the OT world but not in a standardised way. <krit> AmeliaBR: this is kind of how it worked in SVG by saying which parts are not supported. Comes up to quite some details that need to take into account and makes it hard to describe the subset. Especially to avoid any conflicts. <krit> myles: CSS has the design where futures are detectable with fallbacks. Each implementation can support a different set of properties and websites can provide fallback for some browsers and use another for yet another set of browsers. Maybe we should have a similar model in SVG? <krit> myles: Let software detect what is supported and use mechanisms. <krit> AmeliaBR: SVG did have a supported testing feature which was poorly defined and implemented so we dropped it. Sadly w/o any replacement. <AmeliaBR> SVG 1/1.1 Feature strings: https://www.w3.org/TR/SVG11/feature.html <krit> myles: In CSS you can define a property twice. If one doesn't work take the other one. Can we do something similar with attributes? <krit> chris: not really, no <krit> chris: CSS has a document order. In XML each attribute can just be used one and in practice they are in order. <krit> AmeliaBR: There was the idea to use switch element. Test one thing and switch between one element or the other. <krit> AmeliaBR: 2 questions: a) can we define a nice subset with easy way to define which should be supported. b) is it possible to write fallbacks and detections to handle multiple environments. <krit> AmeliaBR: myles on the first question: Have you looked at SVG Native and how this cold be done there? Have you looked into other ways but using the diff as it is done currently? Like using a table with supported values and fallbacks? <krit> myles: I was planning doing that and asked the WG. The advice that I got was to keep it as a comparison with the original document. <krit> AmeliaBR: but in the sense that you do not duplicate content. Doesn't mean that it needs to be done chapter by chapter. Try to find a link from SVG Tiny. <krit> AmeliaBR: SVG Tiny had an appendix with just a table of elements and what is supported. <krit> myles: I think a table in the spec sounds fine and I would be happy to do that. <krit> myles: I think the point here is to find guidlines how different parts interact with it. <krit> AmeliaBR: That would be the first part. 2nd would be defining how conformance tests work with it. <krit> AmeliaBR: We also need to look at extensions in the case of IEC with custom elements and attributes in custom namespaces. <krit> myles: I don't have good ideas how to define or follow good practices. <krit> krit: could AmeliaBR and myles brain storm and see if and how this could be done? <krit> AmeliaBR: myles: I think we can do that. <krit> myles: planning to do another pass soon to add all the resolutions we did in the group yet. <krit> AmeliaBR: and by doing it we should look at all the complications. <krit> AmeliaBR: the other aspect would be how to work with the conformance side of things. <krit> AmeliaBR: How do we deal with browser and non-web environments? Figure our which tests are relevant of this? <krit> myles: are those part of the platform tests for SVG Native? It is not targeting the web. <krit> AmeliaBR: No, but if we take SVG Native as a foundation we should think about it . <krit> krit: maybe we can take it one step after the other and look at conformance 2nd. <krit> myles: I think we should have a list of tests for web platform and non-web tests. <krit> AmeliaBR: definitely one way to go. Concern is that we do not have a suite for SVG2 yet <krit> AmeliaBR: So we would need to look at all new tests to see in which buckets they could go <krit> myles: some amount of gardening is required. Either authors or reviewers/spec editors. Not sure which one is better than the other. <krit> AmeliaBR: So course of action on this issue is to keep everyone updated and use SVG Native as a "test case" of a defined SVG subset. <krit> RESOLUTION: Myles and Amelia brain storm on subsetting specs based on SVG Native and get back to the group |
|
Hello SVG Team,
See attached diagrams that visualize this. We have the following questions:
IEC 61850-6-2 Schema Draft.pdf Thanks for your support. |
|
Hello All, We have a small team prepared to do the bulk of the work, but need to ensure it is aligned with SVG 2, which we understand is emerging. We have also created an SVG profile that will be included as a normative annex. Attached is the latest draft of the standard. SVG Profile is defined in Annex H. We look forward to having your support in developing the SVG 2 schema, which we hope can be jointly shared. Please contact me (dtessier@tescoautomation.com) if you're interested in contributing. Amelia/Myles: Can we organize a quick call? |
AmeliaBR
changed the title
|
Hi Dustin, A belated response to your questions from February (sorry for the lack of response at the time), then I'll try to follow up with a review of the SVG aspects of your draft spec:
|
|
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)… p11
SVG 2 has been published as a Candidate Recommendation, but that is not a stable/final document in the W3C process. A candidate recommendation indicates 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
I would strongly advise against defining a new XML namespace with the 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. p30Figure 6 implies that the full SVG specification is contained within the definition of GCL. But the text later says
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. p34I think the spec nicely summarizes the concept of an SVG Profile as an application-specific subset of the full SVG specification.
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
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? p43It 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). p44I 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! p46Not SVG related, but: You may wish to convert your 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. p49I 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
I assume these sections were written when you were still using SVG 1.1 as your reference. SVG 2 doesn't define either Since the current CSS definitions of these types are rather complex, you probably want to explicitly list which syntaxes are supported. p63The extension to p70−77The 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 Note that refX/refY on Similarly, the 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. |
|
On the question of developing a machine-readable schema, pinging @sideshowbarker for input on what the W3C Validator uses. |
|
For SVG checking, the W3C Validator uses the RelaxNG schema that can be found here: https://github.com/validator/validator/tree/master/schema/svg11 |
|
Thanks for that link, @sideshowbarker. To confirm: although the folder is called |
Correct. More specifically, the aspiration is for it to conform to whatever the current SVG spec happens to require — regardless of what version label the spec might have — in the same way that the schema intends to conform to the current requirements in the HTML (Living) Standard.
Right — but it’s worth noting I’ve only done on that case-by-case, just in response to bug reports from user/developers. Specifically, I’ve not done any systematic audit against the changes made to document-conformance requirements in the spec between SVG 1.1 and the current SVG spec. But if others are able to examine the requirements changed between SVG 1.1 and the current SVG spec, and create issues/PRs for any cases found where the schema and checker aren’t conforming to the current spec requirements, then I’d be happy to spend time updating the schema to bring it into conformance. One thing that’s also worth keeping in mind is that in the checker architecture, the requirements aren’t addressed only by that schema but also by an accompanying datatype-checking library and by some additional custom (Java) code. https://github.com/validator/validator/blob/master/src/nu/validator/datatype/SvgPathData.java for example, a part of the datatype library, is for checking the |
|
@AmeliaBR Thank you for the value-added comments. We have updated the document with your recommendations, and appreciate your feedback. We are close to finalizing the GCL requirements and will have an example GCL file (with the SVG elements and our extensions) available soon. We will share this when available. We will then move towards the SVG and GCL schemas, which will have their own XSD. @sideshowbarker Thank you for the update. We never realized there are on-going developments on the SVG schema with aspirations to make it conformant to SVG2. We were going to develop our own SVG2 schema, but it may be best to utilize your draft version? Would you agree?
|
|
@sideshowbarker Our Taskforce has noticed the following observations with regards to your Schema. Any comments? Some findings: svg-basic-structure.rnc:299:9: error: reference to undefined pattern "common.attrs.aria" |
|
@sideshowbarker We have spent time reviewing the RelaxNG specification and the associated Java to validate the datatypes. We conclude on the following observations:
Any suggestions on how an SVG2 schema can be developed to achieve these three validation checks? |
No, you can’t expect the https://github.com/validator/validator/tree/master/schema/svg11 schema to be in conformance with the SVG2 specification. In fact I’m certain it’s not in full conformance with the SVG2 specification. I don’t know where in particular it’s not in conformance with the SVG2 specification, but I’m also not personally going to audit it against the SVG2 specification to find out. Instead I make updates to it when people file bugs.
I can’t speak to anything abut GCD, because I know nothing about it and how it relates to SVG.
I don’t think you’re going to find any way to transform the Java code into a schema. I wrote a lot of the relevant datatype-checking Java code that my application is using, and I wrote it in Java intentionally. In particular, I am very familiar with Schematron and very intentionally chose not to attempt to write any of the datatype-checking code in Schematron. I am less familiar with XSD but I know enough to be very certain that the datatype checking my application is doing with Java code can’t be done with XSD.
I don’t know what that means. I suppose there’s some context I’m missing. |
It’s not my schema. It was just copied straight from https://www.w3.org/Graphics/SVG/1.1/rng/ and then lightly modified.
I don’t know what you mean by “immature state” but whatever “SVG11 XML schema from Chris” is, it sounds like it might be the same thing as https://www.w3.org/Graphics/SVG/1.1/rng/ — and if so, it’s unsurprising it’s in the same state.
If that’s the case, then I guess I would wonder whether the spec actually clearly sets any further restrictions on them other than just “string”. But it’s not useful to have any discussion about it in the abstract. If there are specific cases where the spec clearly says some particular attribute should be datatyped as more than just “string”, then that’s something tangible which we could have a productive discussion about.
I don’t know what “express linkages between sections” means, or whether any schema languages other than RelaxNG provide some way to “express linkages between sections”.
I don’t know what LNs or LNodeType are, or what value there is in validating linkages between them. But whatever it is, it doesn’t sound like anything that’s part of SVG. So it’s unclear to me what relevance it has to the discussion about a schema for SVG validation.
Whatever checking the https://github.com/validator/validator/tree/master/schema/svg11 is doing for restrictions on how ARIA attributes can be used is based on the normative requirements in the https://w3c.github.io/html-aria/ spec. Is there a some other specification that normatively defines restrictions on how ARIA attributes can be used in SVG?
That’s because the https://github.com/validator/validator/tree/master/schema/svg11 schema isn’t intended to be used outside the context of the HTML checker. The modifications I made to it use hooks that aren’t going to be exposed without the schema being integrated in the HTML schema that the checker uses. |
No, I think you might likely be better off writing an SVG2 schema from scratch based on a rigorous auditing of the restrictions in the SVG2 spec. I have zero confidence that the https://github.com/validator/validator/tree/master/schema/svg11 schema is thoroughly aligned with the current requirements in the SVG2 spec. So if your goal is to have an SVG2 schema that’s well aligned with the SVG2 spec, I think probably the right way to do that would be to write such a schema. |
|
@sideshowbarker That is disappointing to learn the SVG working group does not have a supporting SVG2 schema, nor does it intend to develop one. One of the principle values of adopting a mark-up language is having a corresponding schema that enforces/validates the SVG2 rules in a consistent manner. We strongly encourage the SVG WG to re-consider the priority of this task, and the value that it brings to the overall SVG2 specification. Having a group of power system experts write an SVG2 schema may not be in the best interests of the W3C/SVG WG. Please confirm how the SVG WG would like to proceed with an SVG2 schema? |
|
@dtessier32 I don’t disagree with you, but I’m not actually a member of the SVG working group — I’m just the maintainer of the W3C validator — so I have no influence over what the working group chooses to do (or not do). |
|
@sideshowbarker @AmeliaBR @dirkschulze This was built upon the unofficial RelaxNG, and was translated using TRANG. Attached is the schema and hand-modified RNC files that made them acceptable to the TRANG translator. You can look at the file dates in that folder to see that we modified svg11-inc.rnc plus 5 other files. That folder is attached as SVG11.zip. We also attached a sample SVG file (Android.svg) that was used during the testing process. Summary:
Note that inside the folder is a Windows batch file (RunTrang.b_a_t) which has comments on changes that were needed after the automatic TRANG translation from RelaxNG to XML schema. Most distressing was embedded comments from “hsivonen” who used “—” as comment delimiters. Any thoughts on ownership and maintenance of this draft SVG2 schema? We thank you in advance for any input you may have. |
|
@AmeliaBR @dirkschulze Any opinions on the above post regarding schema developments? We have an upcoming working group meeting and hope to report back on this. Thanks. |
|
Hello SVG WG, Regards, |
Hello All,
We are creating an International Standard for power system HMI applications, referred to as IEC 61850-6-2. This will effectively include:
We are seeking the SVG Task Force's recommendation on the following:
We will post future SVG examples as they are mature.
We look forward to your recommendations and look forward to working closely with the SVG TF to ensure we define harmonized requirements across both Task Forces.
Thanks.
Regards,
Dustin Tessier
dtessier@tesco-group.com
IEC 61850-6-2 Task Force Leader
The text was updated successfully, but these errors were encountered: