Classification Facet behavior is not full about ids

[Moult]

Yeah I was the one who wrote that table and at the time I believe the intention was to encourage users to use the bSDD where possible to guide users on how to input data: 4381e77 - so as you can see it covers classifications, materials, and properties. However the intention was never to actually audit the classification reference location field.

I'll be happy to update the docs to prevent this future confusion, sorry.

[andyward]

1. My understanding is we should check the value at any level in the classification hierarchy (any ancestor). See this test case
2. URI - This is presumably up to the spec author? But I'd assume a link to the particular classification would be most relevant, rather than the system. It's meta data not a testable attribute I believe

[I-Sokolov]

My understanding for 1 is the same, but I'd like to have it clearly declared in the doc.
For 2 it should not be up to spec author because checker developer does not know his intentions:)

[Moult]

The URI is not part of the requirement, it's just metadata. Like the URI in other facets.

[I-Sokolov]

@Moult, I would disagree, in case of classification facet URI declared as parameter, not metadata

[andyward]

Probably needs clarifying in the docs, but my reading on it is that URI is a parameter you'd suggest be could specified by the author/authoring tool, to aid the ultimate users delivering models against the spec.

But I don't think there's any expectation it forms part of the verification parameters. At best it might be something take the user to for more information in the event of a verification failure?

I can also see a structured URI being highly useful to populate a requirement - and indeed some of the object libraries / PDTs services are outputting IDS, where it would make total sense to leave a URI link back to the master data. But there's no saying the URI will be structured. I've seen web pages, PDFs and XLS already in the URI.