Possible buf of SiRPAC (relative URI resolution for "resource" attribute)

Hello.

I'm now developing an application for WAP UAProf, and use SiRPAC RDF parser 
for RDF/XML data parsing. Although most things go smooth, I've found one possible
glitch of SiRPAC concerning the way it resolve relative URI for "resource" or "about" 
attribute's value. I suspect the way SiRPAC resolves such URIs is incorrect.
(May be related to another attributes such as "aboutEach", though I'm not sure about
such details of RDF syntax.)

When "about" or "resource" attribute is specified in each Description element of RDF/XML
data, RDF parser such as SiRPAC must first resolve that URI into the absolute form
in order to create an RDF model. (Each resource in RDF models must have an unique
identifier.) Section 2.1.1 of the RDF model and syntax spec says that such relative URIs
are resolved in accordance with RFC2396 based on the document base URI of RDF/XML data.

In some applications such as CC/PP, it is difficult to tell what is the base URI of particular
RDF/XML data, because data may be embedded into HTTP header and do not exist
in a static and an independent document form, but at least, in the case of RDF/XML parsing
with SiRPAC, we can tell SiRPAC the document base URI by first calling setSystemID() method
for DataSource class and then feed that data to the SiRPAC. SiRPAC seems to consider
the value of systemID property correctly as document base of the RDF/XML data according
to the SAX API semantics.

If we write relative URI for "resource" or "about" attribute, SiRPAC does resolve that URI
to the absolute form, but unfortunately in obviously strange way. 

Please consider the following example:

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:prf="http://www.wapforum.org/UAPROF/ccppschema-19991014#">

<rdf:Description ID="MyProfile">
<prf:component>
    <rdf:Description ID="TerminalHardware">
        <rdf:type resource="http://www.wapforum.org/UAPROF/ccppschema-19991014#HardwarePlatform" />
        <prf:Defaults rdf:resource="hardware_def.rdf" />
        <!-- override the ImageCapable property, and add VoiceInputCapable
        and Keyboard properties -->
        <prf:ImageCapable>Yes</prf:ImageCapable>
        <prf:Keyboard>Disambiguating</prf:Keyboard>
        <prf:VoiceInputCapable>Yes</prf:VoiceInputCapable>
    </rdf:Description>
</prf:component>


I just used relative URI for Default block of the CC/PP data such as
<prf:Defaults rdf:resource="hardware_def.rdf" />.

Suppose that base URI of the data can somehow be determined to be 
http://www.sec.co.jp/rdf/myprofile.rdf

In this case it's natural to be resolved into 
http://www.sec.co.jp/rdf/hadware_def.rdf

but actually SiRPAC resolves it into 
http://www.sec.co.jp/rdf/myprofile.rdf#hadware_def.rdf
This result is the one I will expect for the following description
<prf:Defaults rdf:resource="#hardware_def.rdf" />.

A little inspection of the source code reveals that SiRPAC seems to handle ID
and resource attribute in the same way, which may be one possible cause of this
problem.

The problem exists in both the new version (v1.15) and older versions.

Does anyone tell me SiRPAC’s implementation is right or not.

Thanks in advance.

NOTE 
CC/PP's default blocks are used to determine the default value for the attribute,
and of course it is usually meaningless to use relative URI because such URIs are to
be pointed to the vender's site. But relative URIs can be of some help for making 
test data of my application testing.

/*************************************
 *
 *   Ryo Asai  asai@sec.co.jp                    
 *
 *  Systems Engineering Consultants Co.,Ltd.
 *  Marketing department                         
 *
 *************************************/

Received on Tuesday, 21 November 2000 20:59:54 UTC