RE: [sdo] ISSUE 41: an API for elementForm and attributeForm

Hi Blaise,

 

Right now, as I understand the spec, the default behavior is
both elements and the attributes are rendered “unqualified”, so I’m worried
that your suggestion for generating metadata from DataObjects is a breaking
change.  If we could make the choice freely, I would have preferred your
rule as the default behavior, since this seems to be the more standard XSD
usage.  Also, is your suggestion “in addition to” or “instead of” the
ability to control the qualitification through @xmlPropertyUri? 
  

 

Regarding generating metadata from Java Annotations, I think
this is a nice idea, but we should also be aware that the mapping from
namespace to schema is 1:n, and that, if we were writing the schema per hand,
we could give each schema different “formDefaults”.  How common this is in
practice, I don’t know.

 

Similarly, even when the metadata comes from XSD, we have no
guarantee that we will be splitting up the name space in the same way when the
XSD is rendered.  It could be that 2 schemas are used to define the same
namespace, and each schema has different values for “elementFormDefault”. 
When we later generate XSD from all the types in the namespace, which value
should we use?

 

The fact is, certain details get lost when converting from XSD
to SDO… this is intentional, otherwise, SDO would be just as crazily complex as
XSD.  Obviously, though, we want to be as accurate as possible.  But
here we have a change that doesn’t improve the quality of the mapping at all.
 Here we have a detail that only has to do with how humanly readable the
generated schema is,  with whether or not we need to write the
“form=’qualified’” on every property or have a default value.  

 

Maybe we should add a XSDHelper.generate method that takes some
options, this would give at least a framework for implementing this
functionality.  I think we may need these options anyway, so that we can
supply something like a reverse-schema-resolver, to generate the import
statements for referenced types (e.g., in another namespace).

 

Best Regards,

Ron

 

From:
Blaise Doughan [mailto:] 

Sent: Montag, 14. Juni 2010 17:57

To: 

Subject: Re: [sdo] ISSUE 41: an API for elementForm and attributeForm

 

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

a.     
There
is no way to specify the property URI though the API.

b.     
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