election-services message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [election-services] Language Binding Generators
- From: Richard J Cardone <richcar@us.ibm.com>
- To: "EML TC" <election-services@lists.oasis-open.org>
- Date: Sat, 24 Jan 2009 13:05:46 -0600
David,
The 4 points below are responses to
the 4 corresponding points in your last posting.
1) I agree that EML schema numbering
is valuable and intrinsic to the architecture; I don't suggest that we
change it at all. I only propose that we change the top-level <EML>
element name in schemas so that each type of EML document begins with a
unique and descriptive element. The schema file names don't change.
For example, the 110-electionevent-v5-0.xsd file would be modified
so that the top-level definition <xs:element name="EML">
would now read <xs:element name="EML110ElectionEvent">
(or something similar). In my 1/22 posting, I suggest that this approach
clarifies EML semantics as well as increases the convenience of using language
binding generators with EML.
While we are on the subject, we might
also consider a new v6 schema that would leverage the proposed top-level
element name changes. This new schema would define a unique top-level
element for all EML documents. This new top-level element, however,
differs from the current <EML> definition because it is uniquely
defined in exactly one schema file. For the sake of discussion, I'll
call this new schema 001-emldocument-v6-0.xsd with a top-level element
named <EMLDocument> and defined it as follows:
<xs:element
name="EML001Document">
<xs:complexType>
<xs:choice>
<xs:element ref="EML110ElectionEvent"
/>
<xs:element ref="EML120Interdbt"
/>
<xs:element ref="EML130Response"
/>
...
</xs:choice
</xs:complexType>
</xs:element>
Using the above definition, every EML
document would start with an <EML001Document> element and then contain
content that conforms to exactly one of the other EML schemas. The
nice thing about this design pattern is that language binding generators
would be able to generate a single parser that could parse any valid EML
content, which brings us to my next response.
2) I agree completely, specifications
should be written independent of any particular tool. Language binding
generators, however, are a well-established class of tools for working
with XML schemas and we should at least avoid making it difficult to use
those tools with EML. The last time I checked there were dozens of
such generators available.
3) Versioning is challenging and applications
that use statically generated parsers have to be especially sensitive to
the situation. On the other hand, we want to give developers the
greatest latitude in choosing an XML parsing technology that suits their
applications.
4) As far as documentation changes go,
the EML-Process-Data-Requirements-v5.0 document doesn't seem to reference
the top-level <EML> element at all; the EML-Schema-Descriptions-v5.0
document also does not reference the <EML> tag, though I may have
missed where it's mentioned; and the EML-Data-Dictionary-5.0 document would
have to be extended to include the 28 or so new top-level element names.
As far as how much change is too much change for v6, that sounds
like a topic for another discussion!
Regards,
Rich
----------------------------------
"David RR Webber \(XML\)"
<david@drrw.info>
01/23/2009 10:22 AM
|
To
| Richard J Cardone/Watson/IBM@IBMUS
|
cc
| "EML TC" <election-services@lists.oasis-open.org>
|
Subject
| RE: [election-services] Language Binding
Generators |
|
Rich,
That's one way of looking at it the counter
position goes something like this:
1) Having a set of schemas numbered by
group and function is a powerful plus in the way EML is architected and
organized - I know what the 100, 200, 300, 400, 500 and 600 series do.
2) XMLBeans is just a tool - normally we
do not make specification changes to accommodate tools - that sets an ugly
precedent.
3) Versioning is a challenge for static
content handlers like XMLBeans that generates fixed memory structures.
Obviously the dynamic XSLT style *any* handler approach is more flexible.
So - whether I call a root element something like EML, or VotingRecords
or Foobar - XMLBeans will still have an issue when it comes to V7 release
- since that will be using those same root element names so now that will
be conflicting. It does have ways to overcome this - and we should
simply refer developers to those - the folks over on the XMLBeans dev list
will be happy to explain (BTW - I'm on the XMLBeans dev list!).
4) Making this change would have extreme
knock-on ramifications for the documentation and associated details that
will add considerably to the effort need to produce the EML V6 voting package
for OASIS. Not only that - but the same thing for people who have
implemented V4 and V5 already - code wise.
Thanks, DW
-------- Original Message --------
Subject: RE: [election-services] Language Binding Generators
From: Richard J Cardone <richcar@us.ibm.com>
Date: Thu, January 22, 2009 1:16 am
To: "EML TC" <election-services@lists.oasis-open.org>
David,
I don't remember exactly how customized name mapping is done in Xmlbeans,
but I think it involves the use of a poorly documented configuration file.
I also believe JAXB provides a way to specify non-default class name
mappings, but again I try to avoid these complications whenever possible.
The v6 effort offers us an opportunity to make EML schemas generally
easier to use with code generators. My argument for considering at
this time a change to the top level element names in EML schemas goes like
this:
1. The top level element in an XML document should reflect the contents
of that document. For example, it's reasonable for the top level
element in a purchase order document to be <PurchaseOrder>. Likewise,
it's reasonable for the top level element in an EML ballots document to
be <EMLBallots> (or something similar). In a sense, it's misleading
that dozens of different documents start with the <EML> element even
though their content and use are unrelated.
2. The use of language binding generators is simplified when different
schemas define different top level elements. These generators are
valuable because they remove much of the drudgery and pitfalls of parsing,
reading, and writing complex XML documents, especially when compared to
technologies like SAX and DOM. By using different top level element
names, generators can use their default name mapping algorithms without
causing name conflicts. Using the default name mapping reduces the
burden on developers and generally simplifies applications. Also,
different generators are going to have different levels of support for
name customization and it would be nice to avoid the whole issue.
3. If the installed base of EML 5.0 isn't prohibitively large, then breaking
upward compatibility to EML 6.0 by renaming top level elements to be more
descriptive may be worth it. If we don't do it now, it probably will
never get done. I don't know if any other v6 change breaks upward
compatibility (i.e., requires code changes in applications that use EML
5.0), but the level of near-term disruption needs to be weighed against
long-term payoff.
Rich
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]