Talk:TXTDSC

taken from ProdSpec S-100 part 10 proposal

The product specification imposes special requirements on the content of files named in TXTDSC or NTXTDS or equivalent new attributes intended for formatted text. SNPWG requires such constraints because digital nautical publications need formatted text. Proposals suggest well-known schemas or DTDs whose specifications are publicly available. Examples are HTML 4.01 (“Strict”) or XHTML 1.0 (“Strict”). If the product specification follows the HTML/XHTML approach the use of those standards should be more restricted, saying the content should be valid HTML 4.01 only, without specified tags (<a>, <img>, etc.).

The specification for formatted text content should prohibit dependencies on another component of the data set or external data. These rules mean that scripts, Java, and external CSS stylesheets are prohibited, as are external links (web site addresses may be included, but may not be coded as HTML links). Images may not be used, or used only in strictly limited circumstances. The use of frames should be prohibited.

jens 07:18, 22 August 2008 (CEST)

After having had a discussion with the industrial technical experts of SNPWG yesterday I would like to share some more thought on formats of the files referenced by TXTDSC/NTXTDS. The ideas should be taken into consideration by TSMAD. We are not willing to press the standard in one or the other way. We only intend to ensure that the most options have been discussed.

i. The standard may define a list of acceptable file formats. The advantage is to allow *.txt as well and not forcing HOs to restructure their existing *.txt information into one particular file type like e.g. *.html/ *.xhtml/ *.htm ... No disadvantages spotted so far.

ii. The standard may permit the same information in different files with same file name but different extension; e.g. file abc.txt contains the same information like abc.xml. The advantage is to let the decision which file will be presented on an ECDIS screen to the ECDIS software. This will open a good competition market; which system provides the information in the most convenient way to the mariner. The disadvantage is how to ensure both content versions harmonized and how to convince HOs to provide the information in different formats. However, this might be a HOs or RENC work.

Barrie's reply 2008_08_22

An interesting debate. Much like S-57, S-100 does not prescribe formats for text files other than the character set codes described in the meta data component. The formats are defined in a product specification, and other than taking into consideration potential interoperability issues, is a free choice - txt, XHTML, XML etc. The only other consideration is to be careful if considering proprietary formats like PDF. These are unsuitable for use in ECDIS because the colour palette cannot be controlled for differing light conditions.

The multi-format concept could be mandated in the prod spec, forcing producers to distribute different formats. Obviously data size and maintenance would have to be considered as potential issues.

The topic of mandation is very important considering the experience we have gained and lessons learned from the ENC world. Much of the inconsistency inherent in ENCs from different producers is due to a lack of clear encoding policies prescribed in the prod spec. This will be addressed in S-101.

 David's comments 2008_08_22 

Hi John, Raphael and Jens, Many thanks for this contribution. I have been thinking about how an XHTML, XML or GML file might be used and please forgive my technical ignorance. In the first case, would we need to use a style sheet, or could we operate without? I noticed on page 10 of the enclosure that "external CSS style sheets are prohibited". Secondly it seemed to me, that if we were using XML the data would be tagged and so it was possible that an XML file could be used to provide information on a number of subjects and, if we used GML, it could be for one particular geometry. I am thinking here about simple point features like DgpsStation and much more complex features like a port, or a waterway which contain information on multiple very different subjects. And I then have a further thought, really for John and Raphael. Would there be advantages in referencing the same GML file from a number of different features and expecting an ECDIS or ECS to only return the bit of information requested, preferably in a nicely formatted or structured layout, with relevant and sensible headings, indentation and use of bold, italics, colour and perhaps hyperlinks? Am I in the land of the fairies?

  Raphael 2008_08_25 reply to Barrie

Thanks for your comments. I agree about PDF, and of course the same argument would apply to any format that cannot have different palettes applied to its portrayal. Similar arguments might apply to Microsoft Word, though it might be possible to devise different styles for different conditions for MS Word, it seems too much effort for the benefit, for style designers as well as implementors. So it may be simpler to restrict the list of acceptable formats to text, HTML, XHTML, and XML-based formats.

Concerning mandation - My belief is that marked-up text (HTML, XML, etc.) would be needed only for relatively complex text content, and some (much?) of the existing content of TXTDSC/NTXTDS files should do as well in its current form (i.e., plain text). HTML/XML text would also need more processing than plain text. So mandating multiple formats *everywhere* might be objected to by both HOs and ECDIS manufacturers on the grounds of development and conversion effort and system performance. One compromise might be to mandate (or recommend?) HTML/XML only for more complex content (such as lists and tables).

  Raphael 2008_08_25 reply to David

Thanks for your comments. I will try to answer your questions below.

Stylesheets: We were focusing on "external" in the phrase you quote, defining "external" as "not located on the display system". The system could operate with or without stylesheets supplied by IHO (if there is no stylesheet supplied as part of the data set, there are still the portrayal rules, and manufacturers could write their own style sheets as necessary provided they obey the portrayal rules). IHO needs to be careful about writing stylesheets, because of the possible variety of media, display sizes and resolutions. At the least, stylesheets supplied by IHO should be accompanied by information specifying the conditions they are intended for (e.g., ECDIS, Display size X" to Y", resolution M X N, etc.).

Concerning the other two questions, yes, it would be possible to use a single XML file to provide information about different subjects and different geometry. I think it should make maintenance easier to have one or a few such files in a dataset instead of lots of TXTDSC/NTXTDS files. It would, of course, require new functionality in software for editing charts and processing ENCs and also a new or updated attribute definition.

PS: Hyperlinks - we thought of prohibiting them on the grounds of security and possible inaccessibility (as for stylesheets, I was thinking of hyperlinks pointing outside the local ECDIS system, hyperlinks to resources on the local system should be OK). If someone has thought of a solution to the safety and performance issues of off-system resources, I would be happy to know it.

 David 2008_08_26 reply to Raphael

Dear Raphael, Many thanks for these replies. Thank you for highlighting the ambiguity in the word "external". I had focussed on the word "prohibited". I now see that we are actually talking about concentric rings of prohibition. So if we can ship style sheets with the data or if they are part of, or defined in, the product specification, that's good. I have not thought about whether they need to be universal or mandated by IHO. We may need to tie this down but in general I would prefer to 'prohibit' less and 'allow' more. In my thinking I was not expecting an ECDIS to be able to go on-line so I was not expecting the style sheet to be somewhere else other than on the ECDIS or ECS. When I wrote about hyperlinks I was thinking more about cross-references to other bits of the data-set, although we are also increasingly adding www addresses into publications. So, I would expect customers who are not constrained by the ECDIS security rules to be able to take advantage of these addresses and for these to act as hyperlinks.

  Raphael 2008_08_27 reply to David

You are very welcome. I think we have converged over the stylesheets issue, in envisaging that stylesheets needed for ECDIS or ECS are shipped with the data?

On the question of whether stylesheets should be universal or mandated by IHO, I cannot just now think of a compelling reason for SNPWG/TSMAD to write universal or mandatory stylesheets. I believe the Colours and Symbols rules in S52 will continue in effect for S-10x systems? If so, manufacturers can write their own stylesheets based on the S52 rules and the characteristics of their displays.

For hyperlinks and other methods of including content, what concerns me most is the possibility of an off-system dependency for critical information such as government regulations. There may also be a possible performance penalty because of slow Internet connections.

You may have noticed that the draft also prohibited scripts, Java, and frames. This was to make it less complicated for developers. I am thinking of datasets being processed and displayed by a variety of systems, and it is possible that the content might be processed by software that is not a Web browser (even an ECDIS might do this). Of course, the final decision about what to propose for all these things is up to you and SNPWG.

John also pointed out to me that these techniques (e.g., stylesheet files, XML file with information on multiple subjects, etc.) would imply revising the specifications for the structure of the dataset.

 David 2008_08_27 reply to Raphael

Dear Raphael, I agree that one way ahead could be, as you say, to ship style sheets with the data. I have also understood John's point that referencing an XML file with multiple subjects is a radical departure from the S-57 / S-100 style data structure; and I suspect that that would be way too far out for many. I would like to have a discussion on this point to try to understand any possible benefits. At the moment I have no feel for this. And thank you for the comments about going on line and the possibility for software to try and process content.

  Barrie to all regarding portrayal

Just a little background information from a S-100 perspective. The new exchange catalogue will add numerous formats permitted during data exchange including stylesheets. In terms of ECDIS we are looking to give more freedom to the OEM, particularly in the area of portrayal which gives more opportunity for differentiation. Of course this can be controlled much like the concept of the S-Button approach whereby ENCs can be portrayed by design of the OEM, but default to a standard display when required e.g. for pilots. Whilst on the subject of portrayal, it is still unclear if and how portrayal will be handled in S-100. There will be a register interface much like the feature data dictionaries for symbols and rules. It may well be that S-52 remains as the bespoke portrayal instrument for ECDIS, maintained by CSMWG, and other requirements dealt with on an individual basis.

TSMAD discussions on text attributes

--raphael 16:10, 10 February 2012 (UTC): There is a proposal before TSMAD for modeling OBJNAM, INFORM, and TXTDSC. I have uploaded a file to the Wiki (File:Text attributes.pdf).

jens 17:35, 10 February 2012 (UTC) Thanks Raphael. Actually the file contains only the model for OBJNAM. Are the models for INFORM and TXTDCS identic?

raphael 20:51, 10 February 2012 (UTC): It has information, textualDescription, and name all as complex attributes.

jens 10:39, 11 February 2012 (UTC) oops, I was blind when reading the diagram. Sorry for that.