GetPropertyNamesTest.testGetPropertyNames

[Julian Reschke <ju...@gmx.de>]

Hi.

In this case the following query

	"/jcr:root"

is executed. The test case checks the column names in the result match 
the declared (single-valued) properties on nt:base, plus jcr:path and 
jcr:score.

Questions:

1) Why nt:base? What if "/" has a type with more properties?

2) It doesn't seem to me that the query specifies a type constraint, so 
why the check at all?

3) I thought support for jcr:score was optional???

Best regards, Julian

(open a ticket?)

Re: GetPropertyNamesTest.testGetPropertyNames

[Marcel Reutegger <ma...@gmx.net>]

Julian Reschke wrote:
> I just re-read JSR170, "Section 6.6.3.2 Type Constraint", and it doesn't 
> mention a default constraint. On the other hand, I do agree that always 
> having that constraint, and defaulting it to nt:base makes sense.

I agree the spec should clarify what node type is assumed when no type 
constraint is specified. I think we once had this in the spec but it 
seems it got lost during a re-write of the query section.

> However, I really think the specs needs to state this. Should I open a 
> ticket?

yes, either the maintenance release of jsr 170 or at least jsr 283 
should mention what the behaviour is when there is no type constraint 
specified in an XPath statement.

regards
  marcel

Re: GetPropertyNamesTest.testGetPropertyNames

[Julian Reschke <ju...@gmx.de>]

Julian Reschke schrieb:
> Marcel Reutegger schrieb:
>>> 1) Why nt:base? What if "/" has a type with more properties?
>>
>> If the element test is absent the type constraint defaults to the one 
>> that includes all node types: nt:base
> 
> OK, makes sense, but maybe this could be clarified somewhere in the spec.

OK,

I just re-read JSR170, "Section 6.6.3.2 Type Constraint", and it doesn't 
mention a default constraint. On the other hand, I do agree that always 
having that constraint, and defaulting it to nt:base makes sense.

However, I really think the specs needs to state this. Should I open a 
ticket?

Best regards, Julian

Re: GetPropertyNamesTest.testGetPropertyNames

[Julian Reschke <ju...@gmx.de>]

Marcel Reutegger schrieb:
>> 1) Why nt:base? What if "/" has a type with more properties?
> 
> If the element test is absent the type constraint defaults to the one 
> that includes all node types: nt:base

OK, makes sense, but maybe this could be clarified somewhere in the spec.

> If a query does not explicitly specify properties to select (in SQL this 
> would be a 'select *') the properties of the node type specified by the 
> type constraint are returned. in case of nt:base those properties are 
> jcr:primaryType and jcr:mixinTypes.

Yep.

>> 2) It doesn't seem to me that the query specifies a type constraint, 
>> so why the check at all?
> 
> this is because of the nt:base default described above.

OK.

>> 3) I thought support for jcr:score was optional???
> 
> It is kind of optional. If an implementation is not able to provide a 
> jcr:score it can always return a dummy value.
> 
> The spec says: "As well, a score column will also be included, though it 
> is not required that its contents always be meaningful."

OK.

I'll re-read the spec, and if I still think it needs clarification I'll 
open an issue.

Thanks for the explanation.

Best regards, Julian

Re: GetPropertyNamesTest.testGetPropertyNames

[Marcel Reutegger <ma...@gmx.net>]

Hi Julian,

Julian Reschke wrote:
> Hi.
> 
> In this case the following query
> 
>     "/jcr:root"
> 
> is executed. The test case checks the column names in the result match 
> the declared (single-valued) properties on nt:base, plus jcr:path and 
> jcr:score.
> 
> Questions:
> 
> 1) Why nt:base? What if "/" has a type with more properties?

If the element test is absent the type constraint defaults to the one 
that includes all node types: nt:base

If a query does not explicitly specify properties to select (in SQL 
this would be a 'select *') the properties of the node type specified 
by the type constraint are returned. in case of nt:base those 
properties are jcr:primaryType and jcr:mixinTypes.

> 2) It doesn't seem to me that the query specifies a type constraint, so 
> why the check at all?

this is because of the nt:base default described above.

> 3) I thought support for jcr:score was optional???

It is kind of optional. If an implementation is not able to provide a 
jcr:score it can always return a dummy value.

The spec says: "As well, a score column will also be included, though 
it is not required that its contents always be meaningful."

regards
  marcel