Hi Folks, Consider this input containing a date time value:
20230926T124800Z We can design the DFDL, using the xs:datetime datatype and associated DFDL calendar properties, so that parsing produces this XML: <DateTimeIso>2023-09-26T12:48:00+00:00</DateTimeIso> That is beautiful XML - concise and precise. Next, consider input containing a lat/long value: 2006N-05912E It would be excellent if we could design the DFDL so that parsing produces this: <OriginOfBearing>20°06′N 059°12′E</OriginOfBearing> That is also beautiful XML. In fact, it is possible to achieve this! By hiding the input and then performing a bunch of transformations using dfdl:inputValueCalc. However, that's a terrible approach because, as Mike Beckerle often says, "DFDL is not a transformation language!" If only we had a latlong datatype and associated DFDL latlong properties ..... If only we could extend DFDL ....... How about making DFDL extensible? How about allowing users of DFDL to create their own datatypes (actually, XSD already allows this) and allow users to create their own DFDL properties for the user-defined datatype? That is, how about turning DFDL into extensible DFDL? Thoughts? /Roger
