Closed jrdouceur closed 1 year ago
I have some observations:
MaxDtdlVersion = 2
. I expected elements matching what is available in each version.Could not find an easy way to answer original question: fetch all the units for Acceleration in #92
- I see the same results when using
MaxDtdlVersion = 2
. I expected elements matching what is available in each version.
This seems to be an observation regarding the expectations of MaxDtdlVersion
. At present, the only effect of this option is to reject models that specify a DTDL context version exceeding this value. In other words, this comment does not relate only to the proposed GetImplicitElements() method but rather to the parser's full behavior in regard to the MaxDtdlVersion option. If you believe the parser should provide stronger semantics for this option, please open an issue to this effect. This is a highly non-trivial change.
- Instead of returning all implicit elements, we could split this in different methods, eg: by standard, instance and by extension.
Yes, this is possible. It would be similarly possible to split the extant GetSupplementalTypes() method into multiple methods that partition the types by extension. In the interest of parallelism between the types and the elements, it seems to me that either both methods should be split in this manner or neither should be. Implementing the split is significant additional work because the internal data structures do not at present partition the type and element information in this way.
- In the same way we added break out properties, will be good to provide a better object model to navigate these results, without forcing the "query+casting" pattern.
Are you referring to the casting to DTEnumValue in Tutorial13?
Could not find an easy way to answer original question: fetch all the units for Acceleration in #92
The additions to tutorials 12 and 13 illustrate how fetch all units for Distance (because this type was already used in the tutorial). The answer for Acceleration is a straightforward adaptation of the tutorial code.
var implicitElements = new ModelParser().GetImplicitElements();
foreach (var implicitElement in implicitElements
.Where(i => i.Value.EntityKind == DTEntityKind.Enum && i.Value.Id.OriginalString.StartsWith("dtmi:dtdl:extension:quantitativeTypes"))
.Select(t => (DTEnumInfo)t.Value))
{
Console.WriteLine($"{ModelParser.GetTermOrUri(implicitElement.Id)} {implicitElement.Id}");
foreach (var item in implicitElement.EnumValues)
{
Console.WriteLine($" {item.Name}");
}
}
I would rather prefer something like:
var semanticTypes= new ModelParser().GetSemanticTypes();
foreach (var st in semanticTypes)
{
Console.WriteLine(st.Name);
foreach (var unit in st.Units)
{
Console.WriteLine($" {unit.Name}");
}
}
2 and 3 are very related and might lead to the same solution.
I would not use the implementation effort to drive the best API design.
I did not mean to imply that I think we should avoid a good design because of the work it involves. I agree on the value of a easy-to-use solution.
We can queue up work to both (1) add a highly usable mechanism for accessing units and (2) improve the usability of the type-accessing mechanism, but I don't know either (a) how highly we should prioritize these relative to other work or (b) how quickly we could get these done once the work is started, since this are non-trivial efforts.
In view of the above, my inclination is to provide a mechanism now that (1) provides a perhaps non-ideal mechanism for accessing all model-level information from the metamodels via the parser, to enable use cases that are currently not enabled at all, and that (2) is parallel with the currently offered mechanism for accessing supplemental type information. If we do not do this, I expect it will be quite a while before these use cases are achievable.
Ok, let's publish GetImplicitElements
Can we add a "manual wrapper" to implement GetSemanticTypes and Units?
You mean like in a sample? The way we did with ParseToJson? This seems probably doable. I'll think on it a bit.
Proposal to add a new method to
ModelParser
:This would be analogous to the extant method:
The new method would provide an object model that includes all elements implicitly defined by DTDL, by the standard extensions, and by any partner or feature extension that is directly supported by the parser. Eventually, whenever dynamic extensions are supported, the returned object model will also include elements defined by any extension that has been loaded into the
ModelParser
instance.