election-services message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: [election-services] Language Binding Generators
- From: Richard J Cardone <richcar@us.ibm.com>
- To: EML TC <election-services@lists.oasis-open.org>
- Date: Wed, 21 Jan 2009 13:23:40 -0600
Hi,
I noticed a couple of things regarding
the proposed EML v6 attribute named "Id", which appears as a
required, fixed value on top-level elements on many v6 schemas.
First, an Id attribute that uses different
types is also defined on various elements in emlcore-v6-0.xsd. For
example, the CountMetricStructure element defines an optional Id attribute
with type xs:token; EventQualifierStructure defines an optional Id attribute
with type xs:NMTOKEN; and VoterIdentificationStructure defines an optional
Id attribute with type xs:anySimpleType. In addition, Id is also
used as a subelement name in the same schema file (see ProposerStructure).
This reuse of the same name in different situtations may be confusing.
Second, as far as accommodating language
binding generators, consider the case of Java language binding generators
like Apache Xmlbeans or JAXB. These generators read schema files
and generate Java class libraries that allow XML documents that conform
to those schemas to be conveniently read and written. The names of
the generated classes are taken from the element names defined in the schemas.
Unfortunately, most EML 5.0 (and 6.0) schemas define <EML>
as their top level element. When class libraries are generated for
more than one schema, name conflicts occur when the generator tries to
create multiple classes named "EML".
I don't think the new "Id"
attribute solves the language binding generator problem. One direct
solution to the problem would be to define unique top level elements in
each schema. For example, we could define <EMLBallots> as the
top level element in 410-ballots-v6-0.xsd and <EMLCastVote> as the
top level element in 440-castvote-v6-0.xsd. Java applications that
use both of these schemas can generate binding classes without experiencing
name conflicts.
On a semantic level, one could argue
that XML documents that represent different data, and that conform to different
schemas, should have different top level elements. Having unique
top level elements allows applications to easily determine a documents
type from its top level element. Of course, the proposed Id attribute
also satisfies this document identification problem.
Rich
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]