[
https://issues.apache.org/jira/browse/ACE-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253478#comment-13253478
]
Bram de Kruijff edited comment on ACE-259 at 4/13/12 3:50 PM:
--------------------------------------------------------------
Comitted improved/efficient checking in r1325804
Note on backward compatibility..
The new implementation, like the old implementation, does no XML validation.
However, the old implementation allowed basically anything as long as the first
document node (whatever it is) has an attribute with qName "xmlns:metatype" and
a value that matches a known namespace. The new implementation says: The first
element must have (implied) localName "MetaData" and a namespace (either
default or prefixed) that matches a known namespace.
Thus, really awkward files that may have been accepted by the old
implementation may be rejected by the new one. By example:
These invalid examples will now be rejected:
{code}
<MetaData xmlns:metadata="http://www.osgi.org/xmlns/metatype/v1.0.0";>
</MetaType>
<AnyThingILike xmlns:metadata="http://www.osgi.org/xmlns/metatype/v1.0.0";>
</AnyThingILike>
{code}
These valid examples will now be accepted:
{code}
<MetaData xmlns="http://www.osgi.org/xmlns/metatype/v1.0.0";>
</MetaType>
<foo:MetaData xmlns:foo="http://www.osgi.org/xmlns/metatype/v1.0.0";>
</foo:MetaType>
<metatype:MetaData xmlns:metatype="http://www.osgi.org/xmlns/metatype/v1.0.0";>
</metatype:MetaType>
{code}
was (Author: bramk):
Comitted improved/efficient checking in r1325804
Note on backward compatibility..
The new implementation, like the old implementation, does no XML validation.
However, the old implementation allowed basically anything as long as the first
document node (whatever it is) has an attribute with qName "xmlns:metatype" and
a value that matches a known namespace. The new implementation says: The first
element must have (implied) localName "MetaData" and a namespace (either
default or prefixed) that matches a known namespace.
Thus, really awkward files that may have been accepted by the old
implementation may be rejected by the new one. By example:
These examples will now be rejected:
{code}
<MetaData xmlns:metadata="http://www.osgi.org/xmlns/metatype/v1.0.0";>
</MetaType>
<AnyThingILike xmlns:metadata="http://www.osgi.org/xmlns/metatype/v1.0.0";>
</AnyThingILike>
{code}
These examples will now be accepted:
{code}
<MetaData xmlns="http://www.osgi.org/xmlns/metatype/v1.0.0";>
</MetaType>
<foo:MetaData xmlns:foo="http://www.osgi.org/xmlns/metatype/v1.0.0";>
</foo:MetaType>
<metatype:MetaData xmlns:metatype="http://www.osgi.org/xmlns/metatype/v1.0.0";>
</metatype:MetaType>
{code}
> Support for metatype schema v1.1 (and beyond)
> ---------------------------------------------
>
> Key: ACE-259
> URL: https://issues.apache.org/jira/browse/ACE-259
> Project: ACE
> Issue Type: Improvement
> Reporter: Bram de Kruijff
> Assignee: Marcel Offermans
>
> The configuration helper implementation hardcodes a check for
> "http://www.osgi.org/xmlns/metatype/v1.0.0";, but v1.1 and v.1.2 are also
> valid schemas. AFAICS there is no regression risk in accepting v1.1 and 1.2
> as long as the provider autoconf rp can handle them. Unfortunatly, there is
> no way to express version constraints on this level.
> So..
> 1) Create seperate helpers for v1.1. & v1.2
> 2) Make this helper accept v1.1 & v.1.2
> 3) Rely on org.apache.felix.metatype.MetaDataReader to determine validity
> IMHO option 1 is unnecessarily heavy, option 2 is the easiest fix and option
> 3 the most elegant and robust solution.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
