106516 - mozilla doesn't parse <rdf:_1> etc.

Status: RESOLVED INCOMPLETE

(Core Graveyard :: RDF, defect)

Description

[Chris Waterson]

This was pointed out to my by [e-mail]...

---

[e-mail] wrote:

> >        1. Last recomendation suppress rdf containers but Mozilla
> >           templates *ONLY ?? *accept *Seq,Bag * and *Alt* with* li*
> >           inside. Have you got any plan?
>
> I don't understand the question.

These two rdf documents create the same model using the validator in w3c
http://www.w3.org/RDF/Validator/

    * Using container

    <RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#">   
        <RDF:Bag RDF:about="Bag01">
            <RDF:li>first</RDF:li>
            <RDF:li>second</RDF:li>
        </RDF:Bag>
    </RDF:RDF>

    * Exploited Bag with a property RDF:type [1]


    <RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#">   
        <RDF:Description RDF:about="Bag01">
            <RDF:type>http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag</RDF:type>
            <RDF:_1>first</RDF:_1>
            <RDF:_2>second</RDF:_2>
        </RDF:Description>
    </RDF:RDF>

but they don't create the same model using mozilla.

"To represent a collection of resources, RDF uses an additional resource that
identifies the specific collection (an instance of a collection, in object
modeling terminology). This resource must be declared to be an instance of one
of the container object types defined above. The type property, defined below,
is used to make this declaration. The membership relation between this container
resource and the resources that belong in the collection is defined by a set of
properties defined expressly for this purpose. These membership properties are
named simply "_1", "_2", "_3", etc. Container resources may have other
properties in addition to the membership properties and the type property. Any
such additional statements describe the container; see Section 3.3, Distributive
Referents, for discussion of statements about each of the members themselves."

>From http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/ [1]

But,

"On 29th June 2001, the WG decided that containers will match the typed node
production in the grammar (production 6.13) and that the container specific
productions (productions 6.25 to 6.31) and any references to them be removed
from the grammar. rdf:li elements will be translated to rdf:_nnn elements when
they are found matching either a propertyElt (production 6.12) or a a typedNode
(production 6.13). The decision includes a set of test cases."

>From http://www.w3.org/TR/2001/WD-rdf-syntax-grammar-20010906/ [2]

As far I understand, the standard says to use the property 'type' instead of
'instanceOf' that mozilla use. So mozilla doesn't understand the second model.
Template tag waits for an object with the instanceOf property instead of using
the 'type' property.

In [2] we read w3c wants to remove the containers, no more containers, how will
the template tag works if it looks for rdf:Seq tags in order to create the (bla,
....#instanceOf, bla) statement??

Comment 1

[Chris Waterson]

The only tricky thing about fixing this bug is that we'll need to make sure that
the nextVal property is kept in sync correctly. I'm pretty sure that we don't
have any assumptions about sequentially ordered assertions (i.e., duplicate or
missing indices should still be handled correctly by the enumerators).

Comment 2

[Chase Tingley]

It sounds like the example depends on bug 15006, though that's not inherent to
the issue.

I've read the WG recommendations, and I've put a certain amount of thought into
what needs to be done in order to collapse containers down to the typed node
construction.

The part that stuck out as a potential problem was a requirement illustrated by
one of the test cases:
http://www.w3.org/2000/10/rdf-tests/rdfcore/rdf-containers-syntax-vs-schema/test002.rdf
http://www.w3.org/2000/10/rdf-tests/rdfcore/rdf-containers-syntax-vs-schema/test002.nt
"rdf:li is unaffected by other rdf:_nnn properties", which said that this is
valid RDF:

<rdf:Seq ID="myseq">
  <rdf:_1 rdf:resource="urn:foo" />
  <rdf:li rdf:resource="urn:bar" />
  <rdf:li rdf:resource="urn:quux" />
</rdf:Seq>

Producing the following triples:

[ myseq , rdf:_1 , urn:foo ]
[ myseq , rdf:_1 , urn:bar ]
[ myseq , rdf:_2 , urn:quux ]

That is, the "auto-incrementing" rdf:_nnn are maintained separately from any
that are explicitly named.  How to represent this distinction cleanly in our
datasource model is not entirely clear to me.

Comment 3

[Chase Tingley]

Actually, reading your comment, I realize I need to check up on something --
whether or not the distinction needs to be preserved on re-serialization. 
You're right; other than the fact that the InMemDatasource doesn't allow
duplicates, there may not be anything that prevents us from constructing the
right data model, since we pin the nextVal with an arc.

Comment 4

[Chris Waterson]

Can we leave this as a blocker for the spec violations (bug 11650)?

Comment 5

[Chase Tingley]

Oops -- didn't mean to clear that.  I think it may have been bug 73502 at work.

Comment 6

[benc]

tever is not RDF QA anymore

Comment 7

[Axel Hecht]

waterson left the building