RE: XML Syntax Strawman (ACTION-309)

"Boley, Harold" <Harold.Boley@nrc-cnrc.gc.ca> writes:
> > How do you propose to have the deserializer distinguish between lists
> > and repeated values?    You can't de-serialize to frames without knowing
> > the difference.   (also datatypes, asked in more detail below.)
> 
> Your strawman doesn't mention lists, and we don't have repeated values
> such as {=C0=DD, Taiko} in the abstract syntax. A proposed extension for
> repeated values or finite domains should be discussed separately.
> If found valuable, we can incorporate it into the abstract syntax
> and the fully striped XML.

Yes, many, many separable decisions, not sortable in any good order.

I believe that data structures should match their semantics, and one
should not use a LIST when one means a SET.  I was confident enough that
the WG would make the same decision, if it ever considers the issue in
depth, that I designed the serialization with that in mind.

> >
> > > > The cost of Part 1 is that RDF/XML output tools wont work unless
> > > > modified; the cost of Part 2 is that the XML document has a few =
> bits
> > > > of RDF syntax in it, making it a little bigger and a little
> > > > odd-looking.
> > >=20
> > > And that XML tools will not work on it perfectly well (see above),
> >
> > I don't see where above.  What XML tools will not work on this?  I =
> said
> > "fairly well" because I can't know what all XML tools might do, and =
> how
> > well they work is highly subjective.  All plain XML tools will work in
> > some sense -- it's well-formed XML -- but particular application tools
> > like JAXB make interesting assumptions that might or might not hold.  =
> In
> > some cases the assumptions might be tunable.
> 
> (XSD) validation and (XSL) transformation would not be supported
> by using such a mixture of RIF/XML and RDF/XML:
> a problem for rule interchange.

It's my intent that they be supported.   I may have missed some places
where their support is weak (see below on xsi:type).

> > > and that we would always need two namespaces rif and rdf...=20
> >
> > We'll need at least rif, xs (XML Schema Datatypes), fn (XPath
> > Functions), and whatever the applications need.  I don't see the
> > addition of one more namespace as a problem.
> 
> For pure Horn we only need rif.

I was under the impression that the Horn RIF dialect would include the
ability to express some literal data values (which requires xs) and some
xpath/xquuery functions and operators (which requires fn).  Am I wrong?

> > I understood the sense of the WG to be that when there was a perfectly
> > good term in the rdf namespace, we should use it, rather than copying it
> > into a rif namespace.
> 
> On a case by case basis, but RIF should have its own root, rif:RIF,
> e.g. as in:
> 
> <rif:RIF>
>   <top><Ruleset>...</Ruleset></top>
>   . . .
>   <top><Ruleset>...</Ruleset></top>
>   . . .
>   <top>further top-level RIF object</top>
>   . . .
>   <top>further top-level RIF object</top>
> </rif:RIF>

Why?   What does that do for us that rdf:RDF does not do?

> > > >   3. When serializing a data value (except text strings), we use
> > > >      the rdf:datatype attribute to provide the datatype, like =
> this:
> > > >         <Animal>
> > > >            <age rdf:datatype=3D3D"&xsd;int">12</age>
> > > >            <born =
> rdf:datatype=3D3D"&xsd;datetime">1995-05-28</born>
> > > >         </Animal>
> > > >
> > > >      (In this example, I'm using a defined XML entity for "xsd" to
> > > >      make the string more readable.)
> > >=20
> > > Still quite hard to read. RIF should refer to XSD datatypes =
> directly.
> >
> > What do you mean "directly"?   What alternative do you suggest?   What
> > syntax would you use for the above example?
> 
> With "directly" I mean directly based on XSD, as in
> xsi:type=3D"&xsd;int" and xsi:type=3D"&xsd;dateTime"
> <http://www.w3.org/TR/xmlschema-1/#xsi_type>.

I see.  Yes, this is a nasty fork in the road between XML and RDF, and a
place where I don't think I can square the circle.  I guess we'll have
to survey and see which toolset needs its type information more.  Or
maybe we can come up with some clever hack to make both sets of tools
work.   (Gah -- maybe we can specify BOTH xsi:type and rdf:datatype.
That would be horrible.)

> > Again, I don't see the alternative, if we want deserializers to be =
> able
> > to work without a schema.  Without some flag like this, they can't =
> know
> > whether to read the data into a hash table or a list.  There are about
> > six different ways to do this flag, but I see no real advantage to one
> > over the other, except that this happens to be the same as RDF uses, =
> so
> > it should be the default unless one of the others has a significant
> > advantage.
> 
> The deserializer exploits the natural child order of repeated roles
> such as of the arg role. The example,

That's one way to do it.  I'm proposing a different way.  This comes
back to whether the deserializer can tell the difference between a LIST
and a SET.  I think that ability is important enough to put a flag
(rdf:parseType="Collection") into the XML serialization, and you seem to
be saying we should just use LISTs for everything.

     -- Sandro

Received on Tuesday, 17 July 2007 03:31:45 UTC