Re: parseType"2literal"

Jeremy Carroll writes:

> >
> >   I still don't know why there are so many problems...
> 
> 
> It's XML's fault :)
> 
> XML does not fully support embedding of one XML document within another.
> 
> >
> >   First of all, rdf doesn't allow name of resources like "q:name", or it
> > accepts it but it doesn't translate the q to the namespace defined,
> 
> Correct, we are only talking about qnames in attributes valeus in xml
> literals in RDF.
> (Fairly specialised!).
> 
> >                                                               but if
> > you add xml in your literals, you need to know what namespaces are using,
> > etc...
> 
> Yes.
> 
> >           why don't we leave the literal as it is,
> 
> Running above an XML parser, this is not possible. Minimally things not in
> infoset are lost.
> 
> Running above an XPath Nodeset based XML processor (e.g. XSLT) more than
> that is lost, including some namespace declarations.
> 
> >                                                when user loads this
> > literal he will try to read it and if he doesn't have this namespace
> > defined it will fault.
> 
> One possible choice is that namespaces get transmitted independently of the
> xml literal. Then if the namespaces are not defined it is the document
> user's fault.
> 
> Another possible choice, is that the namespaces must be declared within the
> xml literal. Then again if they are not, it is the document author's fault.
> That choice is attractive, except that it prohibits an XSLT based
> preprocessing of RDF/XML.
> 
> >
> >   By the way, why RDF doesn't interpret the namespaces in the attributes
> > values?? will it do in the future? I don't understand why it
> > doesn't do it.
> 
> RDF2 is likely to in my view.
> No one argues against it.
> 
> RDF M&S (and hence the new specs) do not allow it because XML did not allow
> it at the time.
> 
> >
> >   My proposal is to leave the literals as strings, when the user ask for
> > this string, rdf should return this string, the user must interpret is as
> > xml and fail if there is any error in the xml.
> 
> This proposal is in opposition to the desire to permit processing of RDF/XML
> by standard XML tools (such as a SAX2 parser). The strings include things
> not in infoset and hence not accessible from XML apis.

   Ups, I didn't thought about this option, we never used xslt in rdf
models, for us, a rdf is a rdf not a xml, if we want a xml to transform we
create the xml using the rdf, but with our know structure, keep in mind
that xslt doesn't know anything about references so

   <a>
     <b rdf:resource=c/>
   </a>
   <c/>

   itīs different for xslt than

   <a>
     <b rdf:resource=c>
        <c>
     </b>
   </a>
 
  So, the use of rdf in xslt is not as easy as you can thought at the
begining.

  Are you thinking in all the issues?

  attributes or elements (I can represent the same using both of them in
rdf)
  <a b="c"/>
    itīs the same that
  <a>
     <b>c</b>
  </a>

  And properties can be represented in different xml places
  <a b='c'/>
  <x/>
  <a d='e'/>
 
  or even
  <a b='c'/>
  <x>
    <b rdf:resourceType="Resource">
      <a d='e'/>
    </b>
  </x>

  do you think is a good option use rdf as it was just xml?

  Good luck,
           Marc

> >
> >   Why?
> >   Imagine I want to define my views in rdf, so I will have something like
> >   <rdf:rdf>
> >      <own:page rdf:parseType="Resource">
> >         <own:header rdf:parseType="Literal">
> >              //xml tags to create our page (xul)
> >         <own:header>
> >         <own:content rdf:parseType="Literal">
> >              // my content in xul
> >         <own:content>
> >         <own:foot rdf:parseType="Literal">
> >              //xml closing the tags opened in header (xul)
> >         <own:foot>
> >      </own:page>
> >   </rdf:rdf>
> >
> >   I don't want to process the info in the resources, I want to create a
> > full document and send it to mozilla.
> >
> >   Is it possible? doesn't anybody else need this functionallity?
> >
> >   Thanks,
> >          Marc
> >
> >
> 

Received on Tuesday, 12 March 2002 06:11:12 UTC