Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: The Goals of XML at 25, and the one thing that XML now nee
 Arjun wrote: Implicit conventions are quite common in internal pipelines. The conversions from text to other data typeshas to happen somewhere; I'm not seeing why it's easier overall for this to be in the parser. Or maybe I'm not getting the point here? Automatic data binding. For a datatype to be attached to the parse tree (DOM etc) as a primitive type (a la C), something has to be told to take the text value and convert it: it could be a program, it could be a schema, or it could be from instance syntax (i.e. delimiters and lexical patterns). So lets say I have a XSLT script which decorates an incoming document of a standard format with an ISO8601 date in an attribute @D. And then produced XML is sent through the pipeline eventually to another process written in C or Kotlin which, say, reads the data into some kind of DOM. (And I am not someone who understands XML Schemas or which API to use for them, and anyway our system architect has banned variants of standard schemas, in case someone suggests using schemas.) Now, when I want to read that date, I have to produce code which checks that the date is in a correct lexical form, and parses it, and puts it somewhere on the DOM for me to use. Contrast to where the syntax rules for un Contrast this with a richer syntax where the parser (or transducer is the right CS term?) can do those steps automatically with no configuation or coding of that on the server side. The thing is, it is ridiculous (IMHO) to claim that an ISO 8601 date is something that we really need freedom to allow clients to interpret differently and therefore leave it up to the clients developers to determine it is a date: it will only either be parsed as a date or used for string-comparison-based collation (that is why the year and month comes before the day, after all.) Toput this another way, you cannot say what we must be done with a symbol or name or string @X="red" but markup like @Y=2021-07-21 is always going to have one thing done on it first: to be parsed as a date (even if just for validity). Instead of datatype, it might be good for SGML-ers to consider it in terms of NOTATION. SGML did not leave it to the client to figure out what the notation of some text or reference or external entity was, it allowed NOTATION to be selected in the instance. (Of course, in XML on WWW, the notation is the MIME type and carried along as metadata to the resource, instead.) But SGML did not provide a way to declare the NOTATION of an attribute value, doubly not providing it for DTD-less documents. But that is a gap. (Does my memory tell me that HyTime tried to provide facilities that could be used for this kind of thing?) I think it is entirely reasonable and SGML-ish to want to specify the notation used for some attributes. I have no doubt that had ISO 8601 been around and well-established in 1986 for the initial SGML standard, it would have been considered for an attribute type (not saying it would have been adopted.) Cheers Rick On Tue, Jul 20, 2021 at 11:06 PM Arjun Ray <arayq2@gmail.com> wrote: On Tue, 20 Jul 2021 13:04:34 +1000, Rick Jelliffe 
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
