Re: XMLLiterals and Exclusive XML Canonicalization

I must admit, I am a little bit concerned about the direction we are going here. Some things may have an ugly consequence on implementations; while this is all right for important use cases, I am not sure that dumping RDFa code into an XML file is such an important use case that we should go out of our way to get it perfect if it overcomplicates implementations...


On Oct 24, 2010, at 06:09 , Manu Sporny wrote:

> On 10/22/2010 07:52 PM, Gregg Kellogg wrote:
>>    * Problems with @xmlns propogation to XMLLiterals given Exclusive
>>      Canonical XML rules
>>    * Potential need to keep @prefix and @xmlns separate in Evaluation
>>      Context
>>    * Need to keep in-scope @profiles in Evaluation Context
> 
> Yeah, I think you're right Gregg. The spirit of the XMLLiteral
> serialization rules that the RDFa Task Force created a long time ago
> ensured that active mappings were placed into the generated XMLLiteral
> via @xmlns. @prefix needs to be preserved now as well, but I'm not sure
> if we remembered to make that point in the document.

It is definitely not mentioned in the current document. 

I actually wonder whether we indeed have to reproduce @prefix. We have to put there the @xmlns statements because otherwise the generated XML is invalid. So we do it. The @xmlns syntax for RDFa is equivalent to @prefix; though deprecated, it is still valid. Ie, the generated XML+RDFa would generate the same RDF triples if encoded in @xmlns and, at the end of the day, this is what counts.

> Furthermore, the
> way that you preserve @xmlns and the way that you preserve @prefix need
> to be done very carefully.
> 
>> Is there any expectation that @xmlns mappings and @prefix mappings be
>> kept distinct?
> 
> Yes, I believe that this is true. You need to now track where certain
> mappings came from. That is, did they come from @xmlns, @prefix or a
> @profile attribute?
> 

Why? What is the use case that requires keeping the distinction?

This is where the implementation becomes too complicated. At the moment, one can generate a single prefix table (and term table) which, at a given node, acts as some sort a local state. Except for this point, the processing steps do not depend on whether a prefix mapping comes from an @xmlns, from a @prefix or from a @profile; there is no reason to keep their origins. This would require a triple administration for these tables just for the sake of reproducing them in a very special use case, namely when somebody wants to generate an XML Literal that also happens to be an RDFa code.

What counts, in my view, is that the RDFa code in the XML Literal would reproduce the same RDF triples. By just dumping @xmlns (or, maybe, a @prefix, but I am not sure) onto the top element should be perfectly enough. 

Ivan

> As for keeping track of active profiles, you'll need to do that too in
> order to make sure that the generated XMLLiteral preserves all necessary
> state information.
> 
> Somebody more familiar with Exclusive Canonical XML rules will have to
> answer your question about that - I remember there being a specific
> reason we chose the form that we did, but can't remember what it was.
> 
> So, the rules probably go something like this:
> 
> - For all prefixes defined via xmlns, follow the old XMLLiteral
> generation rules.
> - Ensure that prefixes defined via @prefix are placed into a @prefix
> attribute on the XMLLiteral
> - Ensure that all active @profiles are preserved in the @profile
> attribute for the XMLLiteral.
> 
> I remember it being that generated XMLLiterals didn't have to be the
> same... in that, if the XMLLiteral expressed the proper semantics, it
> was valid RDFa output.
> 
> I think that we should deal with your input as a Last Call
> comment/issue, would that work for you?
> 
> -- manu
> 
> -- 
> Manu Sporny (skype: msporny, twitter: manusporny)
> President/CEO - Digital Bazaar, Inc.
> blog: Saving Journalism - The PaySwarm Developer API
> http://digitalbazaar.com/2010/09/12/payswarm-api/
> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf