XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] The Goals of XML at 25, and the one thing that XML now needs

 On Wed, 21 Jul 2021 00:45:31 +1000, Rick Jelliffe
<rjelliffe@allette.com.au> wrote:
| Arjun wrote:
|  *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).

Isn't that the job of the ETL subsystem responsible for loading a DOM
that is - or should be! - fit for purpose? (But yes, working with
generic DOMs would place that burden on the application.)  

| 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.

Or a LPD?  (Nah. Too bad ISO8879 bollixed the definition of LINK.)

| 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 trouble with that is the universe of such useful auto-conversions
is unbounded.  Why stop at ISO8601 dates?  (How about Roverdates[*],
or DbaseIIdates, which are YYYYMMDD, 32-bit ints in C parlance?)

Customizing the ETL layer seems wiser, from a system design POV.

[*] After Rover, Salomon Brothers' hoary database (back then, some
well-known databases on Wall Street had names like Spot and Fido...)

| 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

I always thought the argument was to leave to the client the decision
to use ISO8601 at all, as opposed to some other scheme.
 
| Instead of datatype, it might be good for SGML-ers to consider it in 
| terms of NOTATION. 

Now there's an idea! (And bring in data attributes as well?)

| But SGML did not provide a way to declare the NOTATION of an
| attribute value, doubly not providing it for DTD-less documents.

Actually, Annex K in the WebSGML TC did, but they could have added
that for elements as well.

    http://users.nyct.net/~aray/sgo/dcnsyntax.txt

(That went nowhere, of course, and now that Google has fubar-ed its
Dejanews takeover, the CTS archive is inaccessible altogether.) 

| I think it is entirely reasonable and SGML-ish to want to specify the 
| notation used for some attributes.

The case for DTD-less documents is harder, and I think intractable
within the confines of the spartan syntax of XML.  There are other
punctuation characters that could be put to good use.  And the case of
simple elements, with #PCDATA content models, are very suitable
candidates for content notations and shorthand based on the old NET
style:

	<myItem someAtt="someVal" /data content here/>

This can be extended with other content delimiters

    <myItem format="iso8601" /@2021-07-20/>

And so on.  I don't think we can get by with just the current syntax.
 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS