Re: XML namespaces on the Web - proposal restated

Dear WGs,
(Ccing public-xml-processing-model-comments@w3.org.)

>> Much less. You write it once, it's very small (usually) and applied
>> not only to a single arbitrarily large document, but any set thereof
>> you may create. For virtually all use cases you'll be able to readily
>> find one suitable for your needs on the Internet (I'd be willing to
>> put up a service for finding or generating them based on requirements
>> stated by the user). A typical author wouldn't ever write one. I
>> believe even that Liam went too far in his simplification.
>> Unobtrusive Namespaces markup language is an XML dialect and it
>> merits its own namespace.
> 
> The most serious problem with this proposal is that if browsers would be 
> required to download these external namespace definition files, then it 
> will inevitably create a single point of failure in these centralised 
> services that you're talking about.  If a popular one were to go down, 
> all the sites relying on it for providing the namespace definition files 
> would suddenly lose their namespaces.
I realised the lesson learnt with RSS and other considerations and I assumed there was a well known solution, so I didn't mention it. User agents may recognise certain URIs and apply appropriate processing without requesting resources identified by them from the network. Another fallback (beside actually sending a request to that URI, if the scheme and configuration warrant) could consist in copies hosted by vendors of some definition resources known to be supported by particular UAs. To resolve a URI doesn't necessarily mean to request a representation, so it's all legal anyway, but informative guidance could be provided.

I'd like to also make a general remark. When deficiencies are identified in various proposals discussed in this thread, please take into account that to satisfy all of our wishes we may need not just one new spec. A proposal which doesn't solve all problems but doesn't preclude using something else for the rest is good and shouldn't be rejected just because it doesn't do X. I'm getting more and more convinced that we need an approach with two layers. Some proposals mix them (which is suboptimal) and some are insufficient because of belonging to the lower layer and having no conterpart. (Some existing specs, like Namespaces in XML themselves, XLink, HLink , DSRL, XInclude, xml-stylesheet, etc., also belong there.) What should constitute the upper layer? Something like [1], I believe - I mentioned it before and it looks very promising. A processing instruction (already proposed in this thread, I don't remember by whom) modyfing the default processing model would be useful, as well as a IANA registry of values for use with this PI. Allowing a registered simple value (along the lines of <?xml-process HTML5?>, possibly instead of DOCTYPE) or something more elaborate and defining profiles of conformance (with minimal requiring just an arbitrary subset of the registered values including "default") would marry the best of both worlds: centralized and decentralized extensibility. I'm likely to sketch a proposal with more details in December.
</trailer> ;-)

Best regards,

Krzysztof Maczyński
Invited Expert, HTML WG


[1] http://www.w3.org/XML/XProc/docs/defproc

Received on Saturday, 21 November 2009 14:58:56 UTC