IHO S100SVG schemas and metadata details

[MikusRL]

@rmalyankar Re S100SVG metadata from #28. You wrote:

"S-100 Part 17 does not apply to this "SVG metadata", nor do 4 or 4a. There isn't any documentation of SVG metadata apart from 9-B-2-4.

The SVG metadata schema is online at https://schemas.s100dev.net/ (scroll down to the Part 9 section and look for S-100 SVG metadata, it has only publisher, creationDate, source, format, version.)"

Thank you for this link. It is very helpful. I trust that we need here this issue open for to have a place where to discuss the unclear questions and news about the expected input for the metadata in the svg files to harmonized more or less before registered in the IHO GI Registy Portrayal Register.

If it would not be too much for one issue, we then could also include here questions on other svg encoding regarding how it is in the schemas.

[MikusRL]

In the #28 in the uploaded svg files for BOUMOR02 and 04 I updated the metadata based on what I could understand from the schemas from above link:

"...metadata>

[MikusRL]

@alvarosanuy As these schemas are now complete as version 5.0, I will ask IHO (Yong) if the existing IHO S100Toolkit, which includes the Symbol builder, could be brought up to date according to those. This also would help a lot in generating cleaner first versions or the basis for the symbols correstly from the beginning, and automatically or with some help at least populate the more up to date metadata fields.

[rmalyankar]

@MikusRL:

Another thing would be great, if the schemas could be updated also with the comment strings (green text in schemas) next to the elements, especially required ones, with the expected input string, at least up to date of the schema publising, or just one time add comment, noting the commenting date in the comment itself. It would guide in what is expected. Many times I find myself strugling especially in the metadata, what exactly they need to describe. Like when the date is required, is it the date the file is created, or is it the date of issue of the schema the file is compliant, etc. So it would be great if in couple of words explained the expected input. Would it be possible at some point to add these in the schemas you pointed to @rmalyankar? I trust it would be very helpful to many of us now and many others in the future, who would be finding these schemas wanting to create S-100 compliant svgs for their product specifications, and will prepare the svgs to upload as proposals to the GI Portrayal Register.

The explanations don't appear to be given anywhere, so what the content of schema comments should be is not clear to me either (and it's too late for Edition 5.0.0 schemas). This matter should be postponed to a future edition of S-100. Meanwhile, I think this S-101 Portrayal sub-group can create conventions (which might ultimately make their way into S-100 and the schemas as the requested explanations).

[MikusRL]

@HolgerBothien

I will not travel to Monaco but participate online. Unfortunately we can only discuss here or in MS-Teams if that is appropriate for you. Regarding the SVG profile I see many things to be discussed.

@TDYCARHugh

I am unable to attend the Monaco meeting due to a personal conflict. Happy to be involved in discussions about using/improving the SVG profile.

When I first made the S-100 SVG profile 7 years ago there was a desire to keep it as simple as possible. There was an expectation that some system developers would want to parse and implement the SVG directly instead of being forced to use a full SVG library. So I started with the SVG tiny profile and only included enough instructions to replicate the S-52 symbols. I expected that once other systems started implementing S-100 and product specs got involved in making symbols there would be requests to extend the profile.

@DavidGrant-NIWC

Sorry we won't see you guys in Monaco.

@TDYCARHugh - I agree that the S-100 SVG profile should be kept as simple as possible. However, I think there is ambiguity regarding what subset of SVG Tiny 1.2 is included in S-100. Appendix 9-B is marked normative, but it says:

This appendix describes the subset of SVG elements that have been used in the creation of S-100 SVG symbols and covers the set of SVG elements and associated attributes and properties that are in use by S-100.

* This note is specific to the draft S-101 symbol set.

* It doesn't describe what is actually required, it just says (paraphrasing) "this is what we are currently using". However, the next paragraph says:

The S-100 SVG profile is a subset of the SVG Tiny 1.2 profile http://www.w3.org/TR/SVGTiny12

The subset is not formally defined, so one is left to wonder if a particular SVG feature must be supported or not. I think the intent was to only require supporting the features listed in 9-B-2 and 9-B-3, but it doesn't actually say that anywhere. It says things like:

The style properties used in the draft S-100 SVG symbols include:

so, one is left to wonder if other symbol sets will use additional style properties. There are also some missing style properties that are currently in use: "fill-rule", "shape-rendering", "display", etc.

We have seen this ambiguity play out already - ESRI developed a windmill symbol and wondered why we didn't support the curve instruction (part of the "path" command) in our testbed. Here's what S-100 says about the curve instruction: We have since added support for the curve instruction, but I'm not sure that other implementations will do so until they encounter a symbol which uses it.

So, this was all a long way of saying I think that appendix 9B should be updated for S-100 ed. 6, and it should make it clear exactly what is (and what is not) included in the S-100 SVG profile. I would also like it to specifically say that animation, multimedia, scripting, etc., are not supported.

I have moved some comments from Issue #112, and I propose we continue the discussion here under this Issue, so when we will close the Berth symbol, it will be possible to continue this discussion here.

In that regard what you mentioned @DavidGrant-NIWC I thought that the S-100 Schemas here: https://schemas.s100dev.net/ are now defining what is in, and anything what is not mentioned in there is "out". Or are these schemas not normative, and hence, now what is in these schemas should be respectively in detail be described in the normative part of S-100 standard?

[rmalyankar]

In that regard what you mentioned @DavidGrant-NIWC I thought that the S-100 Schemas here: https://schemas.s100dev.net/ are now defining what is in, and anything what is not mentioned in there is "out". Or are these schemas not normative, and hence, now what is in these schemas should be respectively in detail be described in the normative part of S-100 standard?

The schemas are normative and should be aligned to the appropriate edition of S-100. At present that is only Edition 5.0.

[DavidGrant-NIWC]

In that regard what you mentioned @DavidGrant-NIWC I thought that the S-100 Schemas here: https://schemas.s100dev.net/ are now defining what is in, and anything what is not mentioned in there is "out". Or are these schemas not normative, and hence, now what is in these schemas should be respectively in detail be described in the normative part of S-100 standard?

You are correct about the schemas (I confess that I had forgotten that they had been added), but they still don't resolve the ambiguity. For instance: The style attribute is optional on the path element. When present, which styles must be supported (https://www.w3.org/TR/SVGTiny12/styling.html)? It's not specified anywhere (except kind of in the spec). Currently there is nothing to restrict someone from animating a path component.

Another example: the "d" attribute is required on the path element. What path data (https://www.w3.org/TR/SVGTiny12/paths.html#PathData) must be supported?

[rmalyankar]

Looks like Appendix 9-B needs a review and revisions, and the schemas would then be updated according to the results.

[HolgerBothien]

I agree with a review. The existing definitions are base on what was necessary for the conversion of S-52 symbols. Now new symbols have to be developed and the limitations are huge. Just a few ideas.

• extend the commands of the d attribute for the path element
• Add rx and ry attributes to the rect element in order to create ovals.
• make the space attribute of the svg element optional
• allow the g element
• and many more The text elements should not be used since text can be converted to pathes. This will make the symbols look identical even if the original font is not available at the target system. Note that this is only the start of the discussion. Definitely the schema is not enough since it cannot describe the format of all attributes (or only by really weird patterns).

Btw. All of the inland ENC symbols in the IHO registry are not compliant (they use the g element)

[MikusRL]

And I thought that one part of the approval process in the GI Registry was to look, in the case of symbols for example, if the symbol submitted is compliant with normatives of the S-100 version it is submitted against. (FYI @JeffWootton )

[HolgerBothien]

Yes, but the problem might be that the schema was only developed for Edition 5 and the symbols are registered before. The profile was already in place but who is able to check a symbol file against a written document with ambiguities. The symbols do not use the schema at all, since it did not exists at the time of creation. I don't know how the registry can be updated to make the content compliant to ed. 5.

[MikusRL]

What I meant is as long as there is appropriate metadata for the symbol that goes with it, then I would not see that as a problem. In your mentioned case, metadata value for all earlier registered symbols could be updated with value "S-100 v.4.0.0 or earlier", and all new registered with the version value they have been created against. And if there would be a need for someone to re-use the symbol, but it would be an incompatible earlier version, then they would know they first need to update the symbols svg for it to be compatible with necessary version. Or, if the versions are not backward compatible, then, yes, make a "copy" of the symbol, give it an updated name, and state in it's metadata, that this symbol is an updated version of the concrete other older symbol. That could be one way to manage that? Then the previous symbol would not be "broken" for older systems, as would be left as is, and there would be new one for the newer systems as a new version, but as long as they look the same, and have it in the metadata that this one is a next version of that other one, then the end user on the end system or display would not even notice that there is a difference between those two symbols.

[alvarosanuy]

Portrayal subWG meeting - 12th January 2023

1. @HolgerBothien to lead the drafting and submission of a paper to S100WG. People to assist with the task: @DavidGrant-NIWC @rmalyankar @MikusRL

2. Leave the issue open until a decision is made by the S100WG.

[DavidGrant-NIWC]

Relevant comments from other issues:

https://github.com/S-101-Portrayal-subWG/Working-Documents/issues/92#issuecomment-1419718682

https://github.com/S-101-Portrayal-subWG/Working-Documents/issues/92#issuecomment-1420192896

https://github.com/S-101-Portrayal-subWG/Working-Documents/issues/92#issuecomment-1420444699

https://github.com/S-101-Portrayal-subWG/Working-Documents/issues/92#issuecomment-1420749317

[rmalyankar]

SVG Metadata

The 5.0 SVG1 (https://schemas.s100dev.net/schemas/S100/5.0.0/S100PC/20220705/S100SVG1.xsd) has:

<xs:attribute ref="tns:publisher" use="required"/>
<xs:attribute ref="tns:creationDate" use="required"/>
<xs:attribute ref="tns:source" use="required"/>
<xs:attribute ref="tns:format" use="required"/>
<xs:attribute ref="tns:version" use="required"/>

Is there consensus on adding name (mandatory) and exposition (optional) attributes to SVG metadata? Anything else?

SVG format

Previous comments only have various ideas. Can we expect a draft paper from somebody soon, or consensus in this discussion about some revisions?

Ideas upchain and elsewhere:

1. extend the commands of the d attribute for the path element (how?)
2. Add rx and ry attributes to the rect element in order to create ovals.
3. make the space attribute of the svg element optional
4. allow the g element
5. allow curve instructions?
6. allow relative coordinates?
7. "many more"?
8. Facilitate drawing of graphed data, e.g. time series

[HolgerBothien]

SVG Metadata

I am not sure if we need these two new attributes. The SVG Schema already defines two elements