World Wide Webber

Hi Jim, 

Interesting question on SAML and RESTful usage - we looked at placing it in the HTTP header - just a question of consensus on what the header name is.  

I would argue though that there is little benefit to using SAML tokens in an HTTP header for authz *unless* you use TLS mutual authn; the Relying Party should compare TLS certificate and signature with the one in the SAML token - otherwise, you can send any old SAML token you nicked from your aunt and pretend to be her. 

Cheers, 

Rowland

"XHTML would be an odd fellow in enterprises, which prefer domain specific XML" 

Is there any guidance on using XHTML + microformats vs domain specific XML? It seems more costly to always create domain specific XML.

Re: SAML , absolutely use TLS mutual authn ; short of that someone will have to really try to make a proper S/MIME profile for HTTP or some alternative (and I recall James Clark having hinted about the need for this over a year ago; it's just one of those blindingly obvious things that needs applied expertise) 

Regarding XHTML + microformats, I suggest looking at building a vocabulary with RDF and annotating the webpage with RDFa.  

The page can then be queried with a SPARQL engine that supports RDFa (which many do today) -- much easier than DOM parsing, I might add.

"I suggest looking at building a vocabulary with RDF and annotating the webpage with RDFa. " 

Noooooo... 

"The page can then be queried with a SPARQL engine that supports RDFa (which many do today)" 

I have millions of pages - now what?

That wasn't Chuck's question. The question was an alternative to domain-specific XML.  

Why on earth would you think I was suggesting it's productive to issue a SPARQL query against a million web documents? (similarly, who the heck would issue an XQuery against a million domain-specific XML documents?)

I appreciate both responses, but neither seems to provide an answer to my original question. The question was guidance on using one vs the other. 

RDF & RDFa seems like introducing a third option, which is fine, however I'd still like to know why. 

I'm a REST noob and one thing I find lacking in REST media is discussion around hypermedia formats in enterprise systems. Some suggest XTHML, others custom media types. I'm looking for more specifics on why. 

Is this choice just a minor implementation detail?

The real tradeoff is, are you making life easier for the consumer or the producer of the data? The difference between RDF, XHTML+RDFa/Microformats, and an XML schema has to do with interoperability. One should ask: what agent or server software can interpret that media type? A custom XML vocabulary might be less interoperable than an XHTML page that's annotated with a Microformat or RDFa.  

When we use XHTML or even Atom/Atompub, we're reusing bits of meaning that other people have defined -- but we think are appropriate mappings to our applciation. When your potential audience size is very large, it use useful to layer and modularize your data so it can be interpreted by those that understand XHTML but may not understand your more specific semantics (i.e. the Microformat or RDF schema or OWL ontology).  

There also are cases where your data could reuse an XHTML module and take advantage of widespread interoperability - for example, the Forms module, for describing a GET's URI template or the interface of a POST hyperlink; the Table module for tabular data; or the List module, for describing simple lists. 

On the other hand, if you're dealing with processing, validating, and/or transforming business domain-specific data, it's arguably easier for a developer to just work with colloquial XML that's typed to your business domain, especially if you expect all your consumers to be custom-adapters that will parse or transform that XML. It might be harder for software that was NOT built without your vocabulary in mind to work with your data.... (e.g. a reporting tool). On the other hand, there's plenty of tools that can access XML interfaces and try to make sense of the data, or give you a way of doing so (e.g. a reporting tool's mapping or transformation engine). 

RDF is useful, in my opinion, for two reasons: it can describe interoperable semantics for your data (usually simple stuff like taxonomies), and it can help you model your data like we used to with an RDBMS, keeping your data model independent of the syntax of that data (RDF is independent of syntax, whereas XML is all syntax). But there's a whole world of newness to RDF that makes it somewhat of a niche to this day. I think this will change over time.

This helps. Thanks for the insight.