Ability to indicate whether an "unknown" value is allowed for a feature attribute binding.

[FrankHippmann]

As a background, the table that is part of S-58 check 2000 indicates whether a feature attribute binding allows for an "unknown" attribute value. From the validation perspective, one aim of the feature catalogue was to remove the need for check 2000. Perhaps the ability to encode "unknown" was overlooked when designing the XML schema for the FC, and I just assumed it was already there.

The benefit of having an "allowsUnknown" attribute in the FC (one of David Grant's suggestions) is that the validation checks for unknown would be implicitly defined, meaning that if the FC is updated, there would be no need to also update the validation checks explicitly. As others have pointed out, in the absence of adding "allowsUnknown" to the FC, there would be the need for product specification specific checks for unknown. Both will work, but my preference is for updating the FC.

For the sake of completeness, I assume that this would not only apply to feature/attribute combinations, but also to other object types for which there are attribute bindings.

[rmalyankar]

Changing the feature catalogue model to add such an attribute would entail an S-100 Revision. The namespace in the FC schema would have to be updated.

[DavidGrant-NIWC]

We're working on a proposal for the upcoming S-100 WG targeted for availability in S-100 5.2. I'll post the proposal here for review once it's ready. It will add an attribute to the attribute binding:

[DavidGrant-NIWC]

@jeffwootton wrote:

While I see the merit in the suggestion from Dave, I tend to agree with Raphael that the best solution (for now) is to include Product Specification-specific validation checks to resolve this. In S-58 Check 508 (categorised as Error) is intended to satisfy this requirement - I do not see why something similar cannot be included in S-100-based product Specifications.

The other problem with this from a Data Producer perspective is that the Producer does not always have the source information to populate the attribute with a value. In these cases the Producer should not have to "make something up" just to satisfy a condition in the FC - this to me is a valid use case for allowing a bit of flexibility and if the default question mark symbol appears in the ECDIS display as a result this then this is an indication that there is some information about the feature that is not available.

The proposed change could support automation of these checks:

• 

• 

Part of the issue here is that the concept of unknown attribute values is carried forward from S-57 via the encodings but isn't realized in the S-100 GFM. S100_GF_AttributeType doesn't provide a standard way to represent unknown values, so it must be handled as a special case throughout S-100 and is encoding dependent. We may propose something to address this for S-100 6.0. At minimum, the XSLT portrayal input should clarify how to encode unknown attribute values (using <attributeCode xsi:nil="true"/> vice <attributeCode />).

I also wonder:

• Is it allowed to encode complex attributes as unknown?
  • It's not currently prohibited anywhere...
• How should unknown date/time/dateTime affect date dependent portrayal?
  • Will pose to the S-101 portrayal sub-WG
• Does it make sense to encode unknown for URI/URN/URL?

[rmalyankar]

(Should this be split into three separate issues?)

• Is it allowed to encode complex attributes as unknown?
  • It's not currently prohibited anywhere...

What does unkown mean for a complex attribute? No sub-attributes? No populated sub-attributes?

• Does it make sense to encode unknown for URI/URN/URL?

Why not, if they happen to be mandatory?

[DavidGrant-NIWC]

IMO this issue should be closed. Any changes relating to this issue should be addressed at the S-100 WG level.

[HolgerBothien]

The background of this issue was the check 2000, which is related to the permittedValue list. To solve the problem the permittedValue list must contain the unknownValue as a permitted value. The proposal as made by Dave has the problem that some attributes doesn't have a value (complex attribute). In this case the proposed attribute makes no sense at all. According to the model only simple attributes can have values and are therefore subject of the noValue case. And the encoding might also makes it difficult to store the noValue case, e.g in XML encoding an element of type xs:date (as long as not nillable) must have a value to conform to the schema.

[LizHahessy]

Agreed at VTC 3 04/09/23 to close.