Hi guys,
an old issue gets to the scene again at complex-features land: how to model an
xsd simple type with List<some primitive type> binding.
Guess this is touching the limits of what we can do with the feature model.
Short and tempting answer would be to create just an AttributeType whose
binding is a List. But we loose the allowable content type (is it a list of
integers, of Strings, of Dates?)
Another option is to make a ComplexType with a property of the corresponding
primitive type and unbounded maxOccurs. But since this complex type needs a
property we need a name for the property, which we don't have (should it be
an annonymous property?)
whatever the most appropriate option is, at gml encoding time we have the
actual emf XsdTypeDefinition to help up on how to encode it. So I guess the
question is limited just to how should we represent it?
Gabriel (swimming in darkness)
NOTE: if an xsd type with scalar content has attributes, it is a complex type
with a "simpleContent" content definition. But that's just xsd rules: simple
types don't have attributes. We don't have attributes anyway.
Gabriel Roldán wrote:
One issue at a time..
NOTE: if an xsd type with scalar content has attributes, it is a complex type with a "simpleContent" content definition. But that's just xsd rules: simple types don't have attributes. We don't have attributes anyway.
Schemas often do have types with attributes, so we will need to create complex types to hold these - regardless of whether they are serialised as attributes or contained elements the models will look similar.
NB in real world schemas, many elements are defined by associations to other classes, and the feature type property will be an element that will inherit a attributeGroup that allows the element to be expressed as an external xlink.
We also see this on metadata property patterns emerging out of ISO work.
Rob
On Thursday 22 February 2007 23:18, Rob Atkinson wrote:
Gabriel Roldán wrote:
One issue at a time..
> NOTE: if an xsd type with scalar content has attributes, it is a complex
> type with a "simpleContent" content definition. But that's just xsd
> rules: simple types don't have attributes. We don't have attributes
> anyway.
Schemas often do have types with attributes, so we will need to create
complex types to hold these - regardless of whether they are serialised
as attributes or contained elements the models will look similar.
NB in real world schemas, many elements are defined by associations to
other classes, and the feature type property will be an element that
will inherit a attributeGroup that allows the element to be expressed as
an external xlink.
We also see this on metadata property patterns emerging out of ISO work.
thanks for the quick response.
So, does it means we should map all xml attributes (except gml:id) as a
property of a ComplexType then use the app schema to decide if encode it as
an element or an attribute?
makes a lot of sense to me. (just possible naming conflicts between the
attribute and an actual element I guess)
Gabriel
Rob