That proposal for XML attributes in DFDL has not been prototyped. I believe it is not ready - still only half baked. E.g, the implications of XML attributes' whitespace collapsing behavior are very problematic when using an XML attribute to logically represent data that physically does not conform. XML attributes are entirely unable to represent data that contains, for example, multiple adjacent space characters, or line-endings. If whitespace is significant, attributes won't work.
Today there is XSLT and AI. E.g., chatGPT seems to be able to write XSLT very well from XML snippets and a description or example of what you want out of the transformation. The whole burden of having to write symmetric transforms - one for parsing, the inverse for unparsing, is eliminated when chatGPT writes them both for you. On Wed, Oct 30, 2024 at 4:58 AM Claude Mamo <claude.m...@gmail.com> wrote: > Was there movement on creating attributes from DFDL? I found this > https://cwiki.apache.org/confluence/display/DAFFODIL/Proposal%3A+Extend+DFDL+with+XML+Attribute+Support > but does someone know whether this will be available anytime soon? > > A bit of context. I have a scenario in EDI X12 where (1) the DFDL schema > is very generic and (2) the segment ID needs to be an attribute in the > parent element so that the XPath selectors in Smooks don't easily break > when routing segments. Unfortunately, due to the streaming nature of > Smooks, I can't use something like this for the selector: > */interchange/segment[segmentId/text() > = "GS"]*. The workaround so far is to use indexes (e.g., > */interchange/segment[2]*) but this is bad for various reasons. > > Thanks, > > Claude > > > On Thu, Nov 2, 2023 at 5:10 PM Brutzman, Donald (Don) (CIV) < > brutz...@nps.edu> wrote: > >> I think that the single most significant and powerful extension >> capability for DFDL would be to support attributes. >> >> >> >> XML Schema is highly extensible already and widely deployed. JSON schema >> is pretty consistent and has similar expressive power - if ever finally >> standardized and consistently supported in tools, it might further broaden >> the available information-architecture infrastructure for many applications >> and much of the Web. >> >> >> >> The ability to align DFDL directly with any XML Schema, to support >> consistent mappings of diverse datasets with coherent data models, would be >> major increase in DFDL capability. >> >> >> >> p.s. long-held opinion: skateboards and attributes are not a crime… 8) >> >> >> >> all the best, Don >> >> -- >> >> Don Brutzman Naval Postgraduate School, Code USW/Br >> brutz...@nps.edu >> >> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA >> +1.831.656.2149 >> >> X3D graphics, virtual worlds, navy robotics >> https://faculty.nps.edu/brutzman >> >> >> >> *From:* Mike Beckerle <mbecke...@apache.org> >> *Sent:* Thursday, November 2, 2023 8:27 AM >> *To:* users@daffodil.apache.org >> *Subject:* Re: Proposal: Extensible DFDL >> >> >> >> I think extensibility would be great for DFDL. >> >> >> >> The DFDL workgroup punted on this as there was no such thing as an >> extensible format description language to generalize into a standard. >> >> We realized that unparsing was already breaking a lot of new ground, but >> it was a must-have feature. >> >> >> >> So we had to draw a line somewhere on the number of untested new concepts >> in DFDL or it would never get done. It took 20 years as is to become >> standardized. >> >> >> >> Some format description languages may have been implemented this >> extensible way, but that was not a visible user feature in any one that I >> ever saw. >> >> >> >> As a research effort this is a good idea. Daffodil is available for use >> in prototyping if that's useful, and if it turns out to be valuable it >> could be proposed for inclusion in DFDL in the future. >> >> >> >> Some years ago I suggested this to someone as a thesis topic for a CS PhD >> project, but to my knowledge it didn't go anywhere. >> >> >> >> >> >> On Thu, Nov 2, 2023 at 10:20 AM Roger L Costello <coste...@mitre.org> >> wrote: >> >> 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 >> >>
