Hi Ron,
The approach you describe will result in properly qualified XML
documents, but does not sufficiently handle the schema generation
aspect which I feel is an important use case.
Metadata generation from XML schema:
Namespace qualification rules for properties are clear
Types could remember the schema qualification used on the define
when the generate schema is performed
Metadata generation from Java annotations:
We could add a package level annotation called @SdoXmlSchema that
would allow the settings for elementFormDefault/attributeFormDefault to
be set. This would avoid the need for most XML namespace qualification
needing to be done through annotations (assuming most users want
elementFormDefault="qualified" and attributeFormDefault="unqualified").
Types could remember the schema qualification used on the define
when generate schema is performed.
Metadata generation from DataObjects:
elementFormDefault=qualfied &
attributeFormDefault=unqualified could be assumed when defining
metadata this way.
-Blaise
Barack, Ron wrote:
http://www.osoa.org/jira/browse/SDO-41
Hi Everyone,
Since we don’t have a construct that represents the namespace,
much less the schema, I view would like to defer setting the
elementFormDefault and attributeFormDefaults until we have the
appropriate targets on which to set them. And anyway, we don’t
have a requirement to produce schema that looks like a human wrote it,
so that I think it is 100% satisfactory to specify on the property
themselves whether they should be rendered in XML “qualified” or
“unqualified”. This is a real requirement, IMO, since
it has to do with producing valid XML.
Whether or not a property is rendered with a namespace is
currently determined by the schema (ie, when the type is defined
through XSD) or by looking at the annotations on the Java getter method
(@SdoXmlPropery.propertyUri). It seems to me that the only
real hole here is that
There is no way to specify the property URI though the API.
There is no way to inspect the value.
Both of these issues can be addressed
by adding a new open content property, xmlPropertyUri. We already use
this approach eg in xmlElement.
I was going to make a concrete
proposal with wording, but on reviewing the core spec, I think the
description of xmlElement is extremely poor, and needs to be completely
rewritten. For instance, on reading the spec, it seems
like xmlElement can only be used on openContent properties.
Perhaps we can get some consensus on
the approach during this week’s call, and I can try for a concrete
proposal for next week.
Ron
