On 11/11/2011 08:19, Erik Sundvall wrote:
> Hi!
>
> On Fri, Nov 11, 2011 at 08:34, Diego Bosc?<yampeku at gmail.com> wrote:
>> Although this would work, I think that it would make ADL far less
>> readable
> Some readability thoughts...
>
> When a value (e.g. upper bound) may be either a number or a symbol (*
> or infinity) most recieveing software will need to have logic
> separating the cases anyway, no matter how they are serialized.
> So then I wonder how much harder it would be to include string parsing
> logic so that we can have JSON-fields with string values like...
> "occurrences": "1..*"
well that's my opinion as well, and XML-ers always react badly! The
'proper' parser code for dealing with this form, used in the ADL parser
is (from the .y file):
...
%type <MULTIPLICITY_INTERVAL> c_occurrences c_existence occurrence_spec
existence_spec
...
c_occurrences: -- empty is ok
| SYM_OCCURRENCES SYM_MATCHES SYM_START_CBLOCK occurrence_spec
SYM_END_CBLOCK
{
$$ := $4
}
| SYM_OCCURRENCES error
{
abort_with_error("SOCCF", Void)
}
;
occurrence_spec: cardinality_limit_value -- single integer or '*'
{
if not cardinality_limit_pos_infinity then
create multiplicity_interval.make_point($1)
else
create multiplicity_interval.make_upper_unbounded(0)
cardinality_limit_pos_infinity := False
end
$$ := multiplicity_interval
}
| V_INTEGER SYM_ELLIPSIS cardinality_limit_value
{
if cardinality_limit_pos_infinity then
create multiplicity_interval.make_upper_unbounded($1)
cardinality_limit_pos_infinity := False
else
create multiplicity_interval.make_bounded($1, $3)
end
$$ := multiplicity_interval
}
;
....
cardinality_limit_value: integer_value
{
$$ := $1
}
| '*'
{
cardinality_limit_pos_infinity := True
}
;
But the 'fast dADL' parser doesn't bother with any of that. Here is the
Eiffel code - you can see how simple it is, and how it would work in
Java, Python etc etc. Note that this parser only handles correct
Interval strings, i..e that were generated by the serialiser, not by
some erroneous human hand!
class MULTIPLICITY_INTERVAL
inherit INTERVAL [INTEGER]
make_from_string (a_str: attached STRING)
-- make from a string of the form "n..m" or just "n", where
n and m are integers, or m may be '*'
require
valid_multiplicity_string: valid_multiplicity_string (a_str)
local
a_lower, an_upper, delim_pos: INTEGER
a_mult_str: STRING
do
a_mult_str := a_str.twin
-- remove any spaces
a_mult_str.prune_all (' ')
-- make the interval
delim_pos := a_mult_str.substring_index
(Multiplicity_range_delimiter, 1)
-- n..m case
if delim_pos > 0 then
a_lower := a_mult_str.substring (1, delim_pos-1).to_integer
if a_mult_str.item (a_mult_str.count) =
Multiplicity_unbounded_marker then
make_upper_unbounded (a_lower)
else
an_upper := a_mult_str.substring
(a_mult_str.substring_index (Multiplicity_range_delimiter, 1) +
Multiplicity_range_delimiter.count, a_mult_str.count).to_integer
make_bounded (a_lower, an_upper)
end
-- * case
elseif a_mult_str.item (1) = Multiplicity_unbounded_marker then
make_upper_unbounded (0)
-- m (single integer) case
else
a_lower := a_mult_str.to_integer
make_bounded (a_lower, a_lower)
end
end
Not exactly hard..... but I think XML developers are not used to this,
and seem to prefer the XML-attributes style, which of course is not an
OO structure, but does reduce the size of the XML file significantly.
>
> Will a string pattern be good enough for validation by auto-generated
> validators or does separation into fields clearly make auto-generated
> validators more capable in this case?
>
> Archetypes and templates will likely often be re-used as in-memory
> objects anyway so a little bit of string parsing overhead at startup
> might not have any significant overhead cost.
>
>
> On the other hand if we want to be verbose we could re-use some of the
> formalisms from http://json-schema.org/ Then we get schema validators
> in many programming languages for free
> (http://json-schema.org/implementations.html). Or perhaps json-schema
> should be an output format from something similar to the TDS (template
> data schema) approach?
I guess my assumption is that ADL will always use the most efficient and
human readable form (the proper 'n..m' form), while XML will probably
require the <atttributes rm_attr_name='xxx' card_lower='n'
card_upper='m'> kind of approach. What we do in JSON/YAML/dADL is up for
grabs. My personal feeling for probably YAML and dADL would actually be
to stick with the string 'n..m' form or else the simplified object
property form prposed initially in this thread, but JSONs mind-numbing
simplicity might imply to use the proper full object explosion form - I
assume noone cares how big a JSON file is?
- thomas
