- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 17 Jun 2019 20:47:21 +0000
- To: public-svg-issues@w3.org
The SVG Working Group just discussed `SVG Extensions/Subset profiles ( IEC 61850-6-2)`, and agreed to the following: * `RESOLUTION: Myles and Amelia brain storm on subsetting specs based on SVG Native and get back to the group` <details><summary>The full IRC log of that discussion</summary> <AmeliaBR> Topic: SVG Extensions/Subset profiles ( IEC 61850-6-2)<br> <AmeliaBR> github: https://github.com/w3c/svgwg/issues/699<br> <krit> ScribeNick: krit<br> <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.<br> <krit> AmeliaBR: So the request is to have a way to specify a subset by referencing sections they need.<br> <krit> AmeliaBR: They also ask for an SVG schema that they can include by reference.<br> <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<br> <krit> AmeliaBR: We would also need to define how that can be conformant checked with test suites.<br> <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?<br> <krit> chris: Like the idea but the spec currently has not text support which might make it to minimal.<br> <krit> AmeliaBR: Yeah, some ppl need the full functionality of shapes with all its complexity but not interested in colors.<br> <krit> chris: CSS Colors 4 covers CMYK. Happy to talk to you about integration in SVG Native.<br> <krit> sairus: thanks. So is SVG Full too complex in general?<br> <krit> AmeliaBR: There are differences between authoring tool and rendering applications like web browsers.<br> <krit> AmeliaBR: So we would need to define a conformant viewer and the other side around.<br> <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.<br> <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.<br> <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.<br> <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.<br> <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?<br> <krit> myles: Let software detect what is supported and use mechanisms.<br> <krit> AmeliaBR: SVG did have a supported testing feature which was poorly defined and implemented so we dropped it. Sadly w/o any replacement.<br> <AmeliaBR> SVG 1/1.1 Feature strings: https://www.w3.org/TR/SVG11/feature.html<br> <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?<br> <krit> chris: not really, no<br> <krit> chris: CSS has a document order. In XML each attribute can just be used one and in practice they are in order.<br> <krit> AmeliaBR: There was the idea to use switch element. Test one thing and switch between one element or the other.<br> <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.<br> <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?<br> <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.<br> <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.<br> <krit> AmeliaBR: SVG Tiny had an appendix with just a table of elements and what is supported.<br> <krit> myles: I think a table in the spec sounds fine and I would be happy to do that.<br> <krit> myles: I think the point here is to find guidlines how different parts interact with it.<br> <krit> AmeliaBR: That would be the first part. 2nd would be defining how conformance tests work with it.<br> <krit> AmeliaBR: We also need to look at extensions in the case of IEC with custom elements and attributes in custom namespaces.<br> <krit> myles: I don't have good ideas how to define or follow good practices.<br> <krit> krit: could AmeliaBR and myles brain storm and see if and how this could be done?<br> <krit> AmeliaBR: myles: I think we can do that.<br> <krit> myles: planning to do another pass soon to add all the resolutions we did in the group yet.<br> <krit> AmeliaBR: and by doing it we should look at all the complications.<br> <krit> AmeliaBR: the other aspect would be how to work with the conformance side of things.<br> <krit> AmeliaBR: How do we deal with browser and non-web environments? Figure our which tests are relevant of this?<br> <krit> myles: are those part of the platform tests for SVG Native? It is not targeting the web.<br> <krit> AmeliaBR: No, but if we take SVG Native as a foundation we should think about it .<br> <krit> krit: maybe we can take it one step after the other and look at conformance 2nd.<br> <krit> myles: I think we should have a list of tests for web platform and non-web tests.<br> <krit> AmeliaBR: definitely one way to go. Concern is that we do not have a suite for SVG2 yet<br> <krit> AmeliaBR: So we would need to look at all new tests to see in which buckets they could go<br> <krit> myles: some amount of gardening is required. Either authors or reviewers/spec editors. Not sure which one is better than the other.<br> <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.<br> <krit> RESOLUTION: Myles and Amelia brain storm on subsetting specs based on SVG Native and get back to the group<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/svgwg/issues/699#issuecomment-502844819 using your GitHub account
Received on Monday, 17 June 2019 20:47:24 UTC