for specifying validation rules. Both have the advantage of being
available now.
StanD.
Post by Konstantin IgnatyevApologies for not making myself clearer: I did not mean that Scala
classes, I meant using them to describe structure of documents
because of expressiveness. Other decent IDLs would work too
(https://developers.google.com/protocol-buffers/docs/overview for
example).
And I think that expressiveness of a language is VERY important,
that is why we have domain specific languages like SQL and CSS.
And my another major point is that XSD fails because it mixes
structure with validation. Validation needs its own definition
language but it should not be mixed with structure definition.
Typical rookie mistake ;) like early HTML tried to be structure and
presentation - we just recently started to recover from all that madness.
I don't think the relative expressibility of XSD vs. X is at
issue. It is possible to *express* a typing system in any
language, right? The problem is that a Scala expression is
necessarily going to tie you to the JVM which won't be
acceptable everywhere.
If you have decided that your particular business domain needs
a *universal* type system (which I think is a dubious
goal (hello HL7!), but we'll leave that for another
discussion), I think the means by which you express that type
system
should at least have a couple of properties. It should be...
1. universally parseable, including human eye parsable, and
2. programmatically producible
Of course, with enough work, all programming languages meet
these requirements, but XSD, for whatever limitations it
might have, is built with those properties in mind. (Where XSD
falls down, IMHO is that it isn't really human producible.)
Interestingly, (to me anyway) homoiconic languages like lisp
also have these properties. That's one of the reasons they
deserve a closer look.
StanD.
Well, I think the answer should be something like Scala
classes ;)
Really, because Scala has class Option to capture notion of
case class HCDocument (
id:String,
name:String,
person:Person,
tags:Option[List[String]] = None
)
What useful can be expressed in XSD, but cannot be expressed
as class with optionals?
Note the "useful" adjective, in my books things like schema
definition for ISBN are not useful
http://www.xfront.com/isbn.html
Is it just me or there is a reasonable use for schemas like
that one for ISBN ( all 3589 lines of it)?
I think structure definitions and validations should live in
separate definitions
so implementer can use any validator that makes sense in the
context when it makes sense
On Tue, Nov 26, 2013 at 12:44 PM, Dennis Sosnoski
Post by Jason Osgood...
http://release.niem.gov/niem/3.0/schemas.html
Quite an impressive body of work.
Despite my antipathy towards all things XML, this work must
still be done. If not XSD, then what? I donât have an
answer for that.
Yes, unfortunately I don't have an answer for that either. And
impressive they may be, but these schemas are a real pain to
work with
using JAXB. Layers and layers of classes to dig through to
get to the
actual data. :-(
- Dennis
--
Konstantin Ignatyev
PS: If this is a typical day on planet Earth, humans will add
fifteen million tons of carbon to the atmosphere, destroy 115
square miles of tropical rainforest, create seventy-two miles of
desert, eliminate between forty to one hundred species, erode
seventy-one million tons of topsoil, add 2,700 tons of CFCs to the
stratosphere, and increase their population by 263,000
Bowers, C.A. The Culture of Denial: Why the Environmental Movement
Needs a Strategy for Reforming Universities and Public Schools. New
York: State University of New York Press, 1997: (4) (5) (p.206)