6.X-14 S-100 Language packs

[rmalyankar]

What are the two XSDs currently in the folder for Part 18? I assume Part 18 will explain but as the time I am writing this comment Part 18 is just an outline.

Assuming it is intended for the official distribution of generic schemas, language_pack XSD should have a namespace, or a good reason for not using namespaces.

When included in the S-100 distribution, the XSDs and other files will contain the same license statement as the existing schemas, giving free permission to copy and distribute and a disclaimer saying they are provided as-is (see the 4.0.0 schemas for instances). If this is going to be a problem let the IHO Secretariat and me know ASAP.

[kusala9]

hi Raphael, they're for the development of Part 18 language packs that Holger and I are doing. hoping to finish the draft of the part sometime this week and Holger has drafted schemas. The ones in the folder are works in progress and we will be trying to get them to a draft stage this week. Yes, I agree they should have a namespace - one for Holger to look at (he's doing schemas, I'm doing words). I'll get him to look at it - any suggestion of a namespace. I'll check and make sure the correct license statement is in place as we get it finished. Shouldn't take long - a few other things on the go this week. We can discuss on the metadata call Monday if that helps???

[kusala9]

@HolgerBothien - namespaces? check the releasability/licence statement is in the XSDs...

[HolgerBothien]

Please note that the schema that should go into the part 18 is multi_language_support.xsd. It is using a namespace. The other schema was a prototype from JP, it should be ignored from now or better removed. The associated test files for the official schema are pizza_fc.xml (A test FC compliant to the S-100 schema) and pizza_lang_de.xml (A translation file, without translations so far). The other test files should be removed as well.

[kusala9]

I'll delete the other one - @HolgerBothien the standardised headers from other schemas should be added to the schema. @rmalyankar are you happy with the schema defined in multi-language_support.xsd.? @rmalyankar can you suggest a filename for the language pack schema? maybe S100LP.XSD? OR something like that. The only other two issues to sort out are:

• We need to reference the S-100 schemas for defining producer code. I think that's already in multi-language-support.xsd but we should check to see if we're importing the right elements?
• Need to import the three letter language codes from codelist.xml (i think it does this too) @rmalyankar we need to ensure the ISO639 codes are complete for all IHO member states, do you know if this is the case or does the S-100 version of the codelist need updating?

[kusala9]

I have a new version of the language pack part which is a bit more complete - I'll upload later today.

[kusala9]

This is the email I sent to Holger over the weekend. Just to keep github up to date with discussions :-) A couple of comments....

• I like the identification of the version of the source content. This is so it can apply to any content with a version identifier.
• Should identification be mandatory? In that case it would be a pre-requisite that only XML content with an identifiable version field can be translated? I think this is ok. It is mandatory now - why is it unbounded? So you can have more than one field to qualify the version of the source?
• I think we should lose sha1Hash. Much as I love hashes the URI filename could be a digital signature URI (which we define in Part 15) and it provides good integration with the exchange catalogue mechanisms we have in the metadata part. translation item should have 1..* multiplicity - surely a language pack must have at least one entry?
• ignore this covered in earlier comments.... Raphael comment on github saying need to define a namespace. I think this version has a namespace? He also wants the standard headers you get in all the IHO schemas inserting (for open access)

[HolgerBothien]

I would leave identification optional, if not at least one of or must be used.

is 'unbounded' since one item may not be enough to identify the resource. Good example happen in reality. S-101 FC 1.0.0 has been published by the IHO with different content. was always 1-0-0 but differs. In this case two elements would do the job. I know, this should not happen but has already happened. sha1Hash should stay for cases where the source file has no version information at all. A signature would definitely not doing the job. It is not ensured that all parties involved does now the signature. A hash value can be calculated always. I agree that a language pack should contain some translation item. The use case that there nothing to be translated may be occur. e.g. A symbol file which does not contain an optional description. One could then leave out the entire file but if you add it with an empty list the information is: **Nothing to translate for this file** vs. **I don't know that file**

[HolgerBothien]

Yes there should be a common header in the schema. I would like that to leave that to the keeper of all schemas in order to have it really consistent. Would be nice to mention the author. The namespace also need to be consistent with other namespaces in S-100 and should contain a version number.

[rmalyankar]

Name of XSD file: S100_MultiLanguagePack.xsd? I'll leave the file names to you.

The test files will go in the "samples" folder hierarchy. Again I will leave the file names to you, I will use whatever names they have on GitHub. I do need to know which example files to include and not include, otherwise I will include all the examples on GitHub.

The XSD file I checked Friday validates, whether it "works" is something I will leave to you.

The license will be like the other schemas and there is a file history component that names developers/contributors. For the multi-language pack XSD I assume that would be SevenCsand IIC; let me know if this is correct.

There is no producer code codelist at present, it will have to be defined. I can generate it from the ISO registry.

There are fewer language entries in the codelists file in the 4.0.0 distribution than IHO member states.

The type of any new codelist attributes should be like this example: S100_ProducerCodePropertyType, defined as below, like similar definitions in the ISO schemas:

<element name="S100_ProducerCode" substitutionGroup="gco:CharacterString" type="gco:CodeListValue_Type"/>

`

<attribute ref="gco:nilReason"/>

`

Then add something like this: producer: S100_ProducerCodePropertyType

[kusala9]

thanks Raphael. I think we should definitely try and come up with a list of languages applicable to member states of IHO (although this can be done as the 5.0.0 schemas are put together.) producer codelist we should also try and put together.

[kusala9]

I'm happy with this - seems sensible.

I would leave identification optional, if not at least one of or must be used. is 'unbounded' since one item may not be enough to identify the resource. Good example happen in reality. S-101 FC 1.0.0 has been published by the IHO with different content. was always 1-0-0 but differs. In this case two elements would do the job. I know, this should not happen but has already happened.

less so with this - we can discuss on Wednesday but I don't see why we need a separate hash value when a hash URI does the same thing, and we have hash URIs defined already. So, a separate hash value element adds no value. The language pack implemeter can then refer to the filename or use a hash URI. The exchange set aggregator can do the same thing. Bear in mind we also (now) have a mechanism for referring language packs to the feature catalogue they refer to in CATALOG.XML (the relationship in CATALOG.xml) so we may not need this identifer at all (this one could just be informative). So, maybe we drop the identifier? Needs discussion.

sha1Hash should stay for cases where the source file has no version information at all. A signature would definitely not doing the job. It is not ensured that all parties involved does now the signature. A hash value can be calculated always.

This seems unlikely! I don't mind though.

I agree that a language pack should contain some translation item. The use case that there nothing to be translated may be occur. e.g. A symbol file which does not contain an optional description. One could then leave out the entire file but if you add it with an empty list the information is: Nothing to translate for this file vs. I don't know that file

[HolgerBothien]

I agree with the language. The producer code we do not need for the language pack. May be for the meta data. But the situation will become more difficult. Currently, you can find the producer codes on two different places in the Internet (different content off course) with a code list file we will add a third source. I would recommend only reference to the 'official' registry, a codelist file would need maintenance every time the registry changes. In terms of producer codes this is quite often.

[HolgerBothien]

A new version of the schema, example file was uploaded. Also a word document with the Model, schema documentation, other documentation, and the description of processes.

[kusala9]

A new version of the schema, example file was uploaded. Also a word document with the Model, schema documentation, other documentation, and the description of processes.

thanks - I'll take a look and update the document/files tomorrow some time.