issue-723/724: Further cosmetic edits related to dirLangString#756
issue-723/724: Further cosmetic edits related to dirLangString#756HolgerKnublauch wants to merge 1 commit intogh-pagesfrom
Conversation
Also turned the value range of sh:closed into an enum
TallTed
left a comment
TallTed
left a comment
There was a problem hiding this comment.
Small punctuation changes, and a couple of / replaced with , rdf:.
| <div class="diagram-class-properties-section"> | ||
| <div><a href="#deactivated">sh:deactivated</a> : xsd:boolean</div> | ||
| <div><a href="#message">sh:message</a> : text</div> | ||
| <div><a href="#message">sh:message</a> : xsd:string, rdf:dirLangString/langString or rdf:HTML</div> |
There was a problem hiding this comment.
| <div><a href="#message">sh:message</a> : xsd:string, rdf:dirLangString/langString or rdf:HTML</div> | |
| <div><a href="#message">sh:message</a> : xsd:string, rdf:dirLangString, rdf:langString, or rdf:HTML</div> |
There was a problem hiding this comment.
I did that intentionally because otherwise it was too wide for the box. That's exactly the problem here, and why I went with "text" earlier.
There was a problem hiding this comment.
too wide for the box depends on the active viewport, the available viewport, the user-set base font size, and other factors. Just let it flow to a second (or third, or more) line.
There was a problem hiding this comment.
Here's what I'm now seeing in the PR preview, which is displaying in dark mode for unknown reasons --
Note that the sh:Shape has a sh:message that wraps, even with your /.
If exact presentation matters, the diagram should be an immutable image ... but even then, various user- or device-based settings, preferences, etc., may change what the user actually sees.
Better we be precise with our language, naming, etc., and figure out presentation challenges later — optimally with decisions that optimize presentation throughout our document(s).
There was a problem hiding this comment.
Here is how it looks for me
and you see the sh:description barely fits in the property shape box, and that was after I have added a few pixels.
Yes, all this is very fragile and perhaps of questionable value because it's just a small subset of features anyway. There are various unresolved/proposed additions related to bringing in different tools but they are appear stalled. Unless someone has sufficient time to truly fix this diagram, I would tend to just discard it completely.
| <div><a href="#name">sh:name</a> : xsd:string or rdf:dirLangString or rdf:langString</div> | ||
| <div><a href="#description">sh:description</a> : text</div> | ||
| <div><a href="#name">sh:name</a> : xsd:string or rdf:dirLangString/langString</div> | ||
| <div><a href="#description">sh:description</a> : xsd:string, rdf:dirLangString/langString or rdf:HTML</div> |
There was a problem hiding this comment.
| <div><a href="#description">sh:description</a> : xsd:string, rdf:dirLangString/langString or rdf:HTML</div> | |
| <div><a href="#description">sh:description</a> : xsd:string, rdf:dirLangString, rdf:langString, or rdf:HTML</div> |
There was a problem hiding this comment.
Maybe we should just delete the "UML" diagram altogether and move it to some other overview document.
|
From the discussions between RDF WG and i18n WG, w3c/rdf-concepts#265 (comment) it may not be necessary to include rdf:HTML (unless SHACL wants to). |
Thanks. This would have to be applied to a separate PR than this here, which is entirely cosmetic. But I think allowing rdf:HTML in sh:message makes sense from a user perspective, as it gives more freedom in rendering hyperlinks, bullet lists etc. |
3 participants
Also turned the value range of sh:closed into an enum