[jira] Commented: (JCR-1360) Parsing built-in CND and XML nodetypes does not result in equal nt-definitions

["Stefan Guggisberg (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/JCR-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566174#action_12566174 ] 

Stefan Guggisberg commented on JCR-1360:
----------------------------------------

> I'm not totally sure, if according to the quote above the built-in cnd-definitions are valid at all. 
> since it states, that the nt:base is assumed if no other super type is defined. In the case of the 
> node types above, mix:referenceable is defined to be the only super type, which is not totally 
> true... the non-mixin types are always sub types of nt:base.

i agree that according to 7.2.2.4 the built-in cnd-definitions would be invalid.

however, the definitions in the jsr 283 spec are 'illegal' as well, e.g. 

4.7.24.10 nt:resource 
[nt:resource] > mix:referenceable, 
                mix:mimeTyped, 
                mix:lastModified 
  - jcr:data (binary) primary mandatory 
 

i'd therefore suggest to change the spec wording to something like

"[...] If the node type is not a mixin and either this element is not present or it doesn't include nt:base then a supertype of nt:base is assumed." 

> In either case: From my understanding the node types resulting from parsing
> the xml and the cnd file should be equal.

not necessarily. it depends on how lenient the node type registration handles 
missing/redundant nt:base supertypes declarations. the resulting node types
however should IMO be equal.

> If the definitions are valid, we may need to adjust the CompactNodeTypeDefReader. 

hmm, intelligently applying 'nt:base" super type defaults would a parser require to resolve
and evaluate external node type references.

e.g. given the following node type/mixin definitions:

[mix:foo] mixin

[nt:bar]

=> in the following case, nt:base super type should be assumed:

nt:foo > mix:foo


=> here nt:base super type doesn''t need to be assumed:

nt:foo > nt:bar


resolving external node type references is IMO out of the scope 
of a CND parser.


therefore i'd suggest to just change the spec wording and leave 
the implementation as is.




> Parsing built-in CND and XML nodetypes does not result in equal nt-definitions
> ------------------------------------------------------------------------------
>
>                 Key: JCR-1360
>                 URL: https://issues.apache.org/jira/browse/JCR-1360
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: jackrabbit-core
>            Reporter: angela
>            Priority: Trivial
>         Attachments: 1360.patch
>
>
> i created a test in order to make sure builtin-nodetypes.xml and builtin-nodetypes.cnd provide the same definitions (actually i only wanted to test my own changes).
> it reveals that the existing built-in NodeTypeDefinitions are not equal due to the following reason:
> - in the xml-format nt:base is always specified if no other super type extends from nt:base
> - in the cnd notation the nt:base is omitted (see below for quote from appendix of jsr 283) even if other super type(s) are
>   defined and none of them extends from nt:base.
> this affects the following nodetypes (all extending from mix:referenceable only):
> nt:versionHistory
> nt:version
> nt:frozenNode
> nt:resource
> quote from public-review of jsr 283:
> "7.2.2.4 Supertypes [...]
> After the node type name comes the optional list of supertypes. If this element is not present and the node type is not a mixin (see 7.2.2.5 Options), then a supertype of nt:base is assumed."
> I'm not totally sure, if according to the quote above the built-in cnd-definitions are valid at all. since it states, that the nt:base is assumed if no other super type is defined. In the case of the node types above, mix:referenceable is defined to be the only super type, which is not totally true... the non-mixin types are always sub types of nt:base.
> In either case: From my understanding the node types resulting from parsing the xml and the cnd file should be equal.
> If the definitions are valid, we may need to adjust the CompactNodeTypeDefReader.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.