<krit> ScribeNick: krit
<AmeliaBR> Scribenick: AmeliaBR
krit: Any extra agenda
items?
... I have one
Dirk: For now, we've got the new SVG Native hosting on GH Pages. Everything else is using svgwg.org
Chris: We've got two different build processes. Might be easier to harmonize.
Amelia: GH pages works better if you don't need a build step. If you want to use it with a build step, you either need a separate folder for the built pages, or you need to carefully manage different branches. Either way, built pages go in the repo.
Chris: Yes, so other option is to run the builds & host the build versions separately.
<chris> I think I prefer to not have the built version in the repo
Dirk: So I'm leaning towards contacting Cameron about getting bikeshed builds set up on svgwg.org
Myles: Either way, I want to make sure that builds happen automatically, so there's no chance of a mis-alignment between the source and the build.
Dirk: I agree. Question is whether the auto builds should happen on GitHub or svgwg.org.
<TabAtkins> Reminder: many people use Travis to auto-commit built versions of their specs to their repo, it's quite easy and well-documented at this point.
Chris: Might want to ask Tab or Peter for advice on setting up the Bikeshed build.
<TabAtkins> https://tabatkins.github.io/bikeshed/#travis-ci
Amelia: probably not too hard to
edit it ourselves. The current build toolling is controlled by
make files. We just need the make file to trigger bikeshed
scripts in addition to the Python scripts.
... Then, once we push a change to the tool scripts, we need to
ask Cameron to whitelist it on the server.
Dirk: I'll look into what's possible already on Cameron's server & then we can decide after that.
GitHub: https://github.com/w3c/svgwg/issues/672
Chris: I think we should make these parts of XML not required in a rendering agent. That would avoid a lot of possible issues. But at the same time, a full XML parser could be used.
Myles: Explain.
Chris: We'd disallow these aspects in a SVG Native document. So you'd get the same results whether the rendering agent supports them or not.
Myles: Would the software need a two-step parsing?
Chris: No, XML parsing and validation are separate steps. So the regular XML parser could be used, but if this extra content is there, it would be invalid.
Myles: But what should the software do if it finds a DTD fragment or other feature that isn't supported.
Chris: We haven't really defined that yet. But it wouldn't be an SVG Native document any more.
Myles: Ok. So it seems we agree that we should exclude these features. But I think we need to define what happens when they are there.
Chris: But we also have to decide
that for other features, like SMIL features or text.
... We could have separate validators that confirm whether a
document is valid SVG Native, but the software wouldn't need to
validate prior to rendering.
... I know other file types do that, eg. fonts. But a badly
made font can crash the whole OS.
Myles: So, at what stage would the document be enforced? Would software exporters have to warn if these features are present?
Chris: For software tools, they usually have multiple export paths with different features enabled or not.
Dirk: I agree. Software tools no
what to export when. How they create that doesn't really
matter, so long as the document at the end of the process is
valid SVG Native.
... We can create independent validators that aren't tied to
any particular software (implementation or authoring tool).
Sairus: I think this is reasonable. But at the same time, e.g., fonts do show up with SVG that is outside or subset. So we still need rules on what to do.
Myles: In a classic design, a parser turns a document to a DOM, and then renderer can use that DOM & decide which features are rendered. But if the parser includes an unsupported feature, the DOM tree could be wildly different. At the rendering level, it doesn't know how that was created.
Dirk: I think that's why we should focus the restriction on what is a valid SVG Native document & not say what the renderer should do.
Sairus: But the idea of a subset
is that the missing features are easily skippable. It doesn't
sound like an XML entity is easily skippable.
... if they act like a macro and substantially alter the
document, they should be forbidden.
Amelia: I think we agree that XML entities shouldn't be part of a valid SVG Native document. The question is whether an SVG Native renderer needs to enforce validity.
Dirk: Can we make a resolution of that part that we do agree on?
Amelia: What's the full set of XML features we're disallowing?
Chris: Both external and internal DTD subset are disallowed.
RESOLUTION: A valid SVG Native document must not contain any of the external or internal XML DTD subset.
Amelia: Next question: what does this mean from the software side?
Myles: Three options I see: (1) renderer must support the features (2) renderer must ignore (3) undefined. Not sure what is best.
Chris: I think I prefer the third. If you use a full XML parser, you get what you get. If not, it will be different. For valid content, there won't be a difference. For invalid content, there may be a difference.
Myles: There are currently at least three different implementations that a close to what we'd call an SVG Native renderer. Have we looked at what they do?
Sairus: I don't think so. But given we're working with existing implementations, that leans towards being open.
Myles: Can we resolve pending further research?
Chris: I'd rather do the research first.
Amelia: To clarify, when we talk option 3, do we really mean undefined, or do we mean two possible choices: match full XML, or fully ignore. Can't just do things partly.
Myles: I think that's assumed.
Sairus: I would like to get this resolved sooner. We've got new teams looking at SVG OpenType support, e.g., the FreeType group.
Myles: That's important & if possible it would be great to get them on a call to find out their constraints.
Sairus: Sure. Follow up with me & copy Dirk, since I think they want to build on the renderer he released last week.
Chris: BTW, hooray for Dirk's new SVG Native renderer!
Myles: Can we make a tentative resolution?
Dirk: Let's wait.
Github: https://github.com/w3c/svgwg/issues/664
Chris: to me, file extension and
MIME type are intrically connected. Most servers map extensions
to media type. Different extensions same media type is do-able,
but what's the point?
... Given that there are servers that restrict the use of SVG
(e.g., image uploads from user) because of security
requirements, so a new extension & type is useful.
... The media type is more important. File extension is just a
representation of that.
Dirk: The downside of a new
type/extension is that existing tools would not be able to open
by default.
... But, we are designing a format for the future.
Myles: Implementations can be
divided & some don't currently support all of SVG,
anyway.
... Browsers should render it anyway regardless of Mime type,
right?
Chris: Maybe, but it depends. Browsers do some sniffing, but won't do anything.
Dirk: Browsers may not be the main issue, since they're likely to be early adopters.
Amelia: It may also depend on
what the new type is. If it's still a valid XML type, browsers
may be able to handle it anyway. But desktop software is going
to look at the extension.
... Might need education for authors: you may need to save as a
different extension. Servers may need to respond based on HTTP
headers.
Sairus: Also worth considering whether we want to create a limited set & then expand it in the future. Would that be a different type?
Myles: If we end up creating too many different subsets, I think we then lose any benefit from having a defined subset at all.
Sairus: So we really want this to be the defined scope & then stick with that.
Dirk: Myles also mentioned the possibility of a distinction internally, e.g., a version attribute.
Chris: This is something we've dealt with before, in XML and in SVG. version attribute and profile attribute. And the end result is that it always gets ignored.
Myles: Does that mean that you think a stronger enforcement at Mime type level is necessary.
Chris: I don't know. Just pointing out the difficulties. Need strong implementer support.
Myles: One use case: for the OS, we might want to open a full SVG file in browser, a native SVG file in image preview. So we'd need a different file extension to do that.
Dirk: Are we leaning towards a
decision here?
... From Adobe's perspective, we'd like a clear distinction. We
don't care whether it's internal (attribute) or external
(extension / MIME type).
Sairus: I think we need to think more carefully about all the use cases.
Dirk: Ok, leave the issue open for now.
Amelia: It would help to write out, in the issue, the use cases & pros/cons for each.
Myles: I'm not sure whether my use case also applies to Windows.
Amelia: Yes, file associations to software are keyed on extensions. So you'd need different extensions to associate them with different viewers.
Sairus: BTW, I spoke recently with some of the Microsoft team. Trying to get them engaged in this project.
Myles: Ok, I'll ping them in the GitHub thread & see if we can get some input.
Dirk: The agenda for TPAC has been posted. SVG WG will meet on Thursday & we'll reserve some time in the afternoon for the CG.
trackbot, end telcon
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Default Present: krit, myles, chris, AmeliaBR, sairus Present: krit myles chris AmeliaBR sairus Regrets: Tav Thomas_S Found ScribeNick: krit WARNING: No scribe lines found matching ScribeNick pattern: <krit> ... Found ScribeNick: AmeliaBR Inferring Scribes: krit, AmeliaBR Scribes: krit, AmeliaBR ScribeNicks: krit, AmeliaBR WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 29 Apr 2019 People with action items: WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]