Re: Resource Gloss (Human Readable)
Rick Jelliffe wrote: > From: Jonathan Borden <jborden@m...> > > > Generally when a user types a URL into a browser there is the > > expectation that something which makes sense will appear. At a minimum a > > user who requests text should get text. > > How a user request text from a browser? > > I certainly don't have that expectation. Perhaps not. But directly from the HTTP RFC 2616: [http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html] "12 Content Negotiation Most HTTP responses include an entity which contains information for interpretation by a human user. " and importantly: "Server-driven negotiation is advantageous when the algorithm for selecting from among the available representations is difficult to describe to the user agent, ... " What RDDL provides is both human readable and a description to the user-agent of what representations are available. A representation, in this case, is unambiguously described by the xlink:arcrole (and the well-known arcroles as a start are themselves humanely described in RDDL/arcroles.htm. > If I request a .css or .jpg or .zip > I don't expect to get a text message. It is not http:// that implies text > but the nominal extension .txt or .html. or the Accept: text/css header. A way, per RFC 2616, that a user-agent requests text is via the request header: Accept: text/* It is not at all clear to me that the so-called problems with content-negotiation arise because of implementations -- which I suspect -- or rather are from fundamental flaws in the design -- which others have proffered -- but we've discussed this already and clearly XML-DEV is in general not accepting of content negotiation as a solution to the namespace URI 'problem'... probably because its not a solution to the problem of how to describe a namespace. > > (Perhaps RDDL should also define some attribute which can be added to > documentation elements in extraneous formats to help auto-generation of RDDL > directories; > <xs:schema ...> > <xs:appinfo> > <xs:documentation> > <html:h1>My Schema</html:h1> > <html:p rddl:precis="true"> > My schema is so easy that you do not need anything else. > </html:p> > <rddl:resource .....><html:p>It is an updated version > of my last easy and ultimate schema.</html:p></rddl:resource> > ... > ) Considering this... My main problem is that I generally consider embedding machine processable out of band information within comment sections: evil. Unless there is a general expectation to find xlinks and such within an xsd:documentation element how would XSD software know what to expect there? While occasionally exceptions to this practice might such as the inclusion of javadoc directives within java comments is useful and widely practiced, it would have been even better if such directives had become part of the Java Language Syntax itself. I think such a practice would be acceptable if explicitly included in the XSD specification (not expecting this :-)) > > > RDDL isn't ignoring anyone. I'd say that 99.99% of people who follow a > > URI expect to see something in a browser -- and the rest have a true need > > for the world to be documented. But seriously, the only rational argument > > against an indirection provided by a RDDL document is one of efficiency. > > No, another rational argument is that it is not what a sizeable group of > people actually want and do, and what some specs (e.g., SOAP) promote. You make what is 'being done today' sound as a fait accompli. Are you making a case for the current status quo? Are you making a case for a hardwired and mandatory resolution of a namespace URI into an XSD and nothing else? Are you saying that SOAP promotes this? From my point of view, a sizeable number of people aren't happy with that becoming a defacto interpretation: e.g: namespace :== XSD I don't think most people are saying this. So why would you propose that a namespace URI resolve into *only* a single representation. Looking at this another way, suppose SOAP (or 'x' spec for that matter) does state that messages or documents or whatever be validated against an XSD resolved through the namespace URI: This doesn't mean that some form of indirection, negotiation, redirection etc. happens. Resolution of a URI is handled by software and such resolution can involve indirection. > > > Suppose we provide a servlet which [expletive deleted] in a RDDL directory on the > > server and provides a resource based upon an accept header -- forget the q > > matching for a moment -- so a client which really does want a particular > > content type can ask for it, and the servlet can perform the indirection. > > For clients that don't care or don't know what to ask for a readable RDDL > > document is returned. For those who care, a particular resource format is > > returned (and we can indirect on a x-arcrole: header -- or some such name > > for an xlink:arcrole URI a client might include in the HTTP GET request). > > ll I am asking for is that the cases where > 1) there is no RDDL document but a direct resource, That's up to the server that resolves the namespace URI. What we are trying to do is reduce the pain associated with documenting namespace URIs *and* associating related resources. > 2) that non-RDDL document itself contains <rddl:resource> elements > are explictly part of the RDDL specification. In other words, the focus > should not be on the markup language or the RDDL namespace per se, but on > how to interpret the retrieved documents from URI at which one expects to > find a related-resource. Isn't the content of a non-RDDL document defined by the specification/schema for the particular document format? Is this akin to embedding XHTML content in a non XHTML document? Perhaps that would be generally useful though I'm not sure the world is ready for "Modularization of RDDL" ... for which I see a serious need for you to complete the proposed XHTML m12n XSD :-) Jonathan Borden The Open Healthcare Group http://www.openhealth.org
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format