[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Advantages/disadvantages of extremely simple XML designs

• From: Dimitre Novatchev <dnovatchev@gmail.com>
• To: "Costello, Roger L." <costello@mitre.org>, "xml-dev@l..." <xml-dev@l...>
• Date: Sat, 11 Aug 2018 21:25:29 -0700

 Hi Roger,

> <properties>
>     <entry key="A">A content</entry>
>     <entry key="B">B content</entry>
>     <entry key="C">C content</entry>
>     <entry key="D">D content</entry>
>     ...
> </properties>
>
> Each item of metadata is represented with an <entry> element. The “key” attribute contains the name of the metadata item, and the value of the <entry> element contains the value of the metadata item.
>
> What are the advantages and disadvantages of this type of XML design?


The above is equivalent to using a (typeless) hash-table (key =>
object) -- not a typed Dictionary<K,V>, so one can translate the
question to comparing strongly-typed with weakly-typed programming.

In a hash-table one can put any type of object, even such objects
whose type and existence were not anticipated at design time. This
gives the feeling of freedom, flexibility, extensiblity.

This can be useful for a simple and universal store, that doesn't have
to know anything about the stored data -- still an useful
functionality to have in some cases. Also, if we are in the middle of
a project and we encounter new types of objects that we don't
understand completely, we can "temporarily" store them in a
hash-table, and delay the moment we will deal with them until we need
to, and know more about these objects.

Beside these properties, an advantage is the fact that having no
constraints makes everything easily/immediately storable and gives us
the ability to interpret the same object in more than one way. So we
can change our code that gives type and meaning to such an object,
without having to change its storage mechanism, thus achieving more
flexibility.

One disadvantage is the effort and additional (run) time to
load/convert/deserialize such anonymously-typed objects into
specifically typed ones -- or in other words, to implement dynamic
typing.
Another obvious disadvantage is that the code that deals with such
anonymous objects will have low
readability/understandability/maintainability. Such representation
should be used only at a very low level of a layered system.
Yet another disadvantage is that much less optimization and
compile-time error - raising are possible with dynamic typing. So
expect to have more run-time errors... and repeated time to deal with
these on many occasions. Also expect using the anonymously-typed
objects to consume significantly more processing time than if these
were strongly-typed.


Personally, weak typing is too universal for my taste -- I prefer to
call the object types with their most appropriate names and in their
natural problem domain / context.

Cheers,
Dimitre

On Sat, Aug 11, 2018 at 7:35 AM, Costello, Roger L. <costello@mitre.org> wrote:
>
> Hi Folks,
>
> There is an Apache technology called NiFi. It is used to distribute data. [1]
>
> A feature of NiFi is that a NiFi application will automatically generate metadata about the data it ingests. The metadata is formatted as XML, which has this form:
>
> <properties>
>     <entry key="A">A content</entry>
>     <entry key="B">B content</entry>
>     <entry key="C">C content</entry>
>     <entry key="D">D content</entry>
>     ...
> </properties>
>
>
>
> Each item of metadata is represented with an <entry> element. The “key” attribute contains the name of the metadata item, and the value of the <entry> element contains the value of the metadata item.
>
> What are the advantages and disadvantages of this type of XML design?
>
> Advantages:
>
> The markup is simple and regular: just a root element and one element that is repeated over and over. So, it’s easy to understand and use.
> The design is highly extensible: to represent new metadata items, simply add more <entry> elements. No changes to the markup (i.e., no change to the XML Schema).
>
> Disadvantages:
>
> There is likely to be a constraint (relation) between an <entry>’s @key value and the <entry>’s content:
>
> Examples of co-constraints:
>
> “If @key has the value A, then the content must be a string restricted to 20 characters and must have this pattern: regex”
> “If @key has the value B, then the content must be a member of this enumeration list: foo, bar, blah”
> And so on.
>
>
>
> XML Schema 1.0 doesn’t support co-constraints. [2] So, you need to supplement XSD with Schematron. In some environments, it is simply not feasible to perform both XML Schema validation and Schematron validation.
>
> Consequently, co-constraints go unexpressed. The design hampers the ability to use XML Schema’s powerful constraint mechanisms. Thus, the design hampers the ability to perform powerful error-checking.
>
> Do you agree with these advantages and disadvantages? Are there other advantages and disadvantages?
>
> /Roger
>
> [1] https://nifi.apache.org/
>
> [2] Yes, I know that XSD 1.1 supports co-constraints, but (I assert, without evidence that) there is lesser support for XSD 1.1 than for XSD 1.0 or for Schematron.
>
>




-- 
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
To avoid situations in which you might make mistakes may be the
biggest mistake of all
------------------------------------
Quality means doing it right when no one is looking.
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play
-------------------------------------
To achieve the impossible dream, try going to sleep.
-------------------------------------
Facts do not cease to exist because they are ignored.
-------------------------------------
Typing monkeys will write all Shakespeare's works in 200yrs.Will they
write all patents, too? :)
-------------------------------------
Sanity is madness put to good use.
-------------------------------------
I finally figured out the only reason to be alive is to enjoy it.

• Follow-Ups:
  • Re: Advantages/disadvantages of extremely simple XML designs
    • From: Mukul Gandhi <gandhi.mukul@gmail.com>

• References:
  • Advantages/disadvantages of extremely simple XML designs
    • From: "Costello, Roger L." <costello@mitre.org>