(moved from SyntaxConsiderations)
[TimothyAppnel] The syntax should:
Have a small simple core.
Should be easily and openly extensible through the use of namespaces. The power to scale up and handle complex/rich exchanges and flexible enough to handle what you need.
Consider prior art (RSS, DublinCore) and honor it whenever possible, but not be bound by it.
Complement and leverage existing technology infrastructure -- HTTP (duh), SOAP.
[SeanMcGrath RefactorOk] This one may be a lost cause but here goes - please, please avoid using XML namespaces! The complexities these things add to processing, XPath navigation, etc. are not justified by the benefits.
Its all about disambiguating elements. How to tell my "amount" element from yours. All you need for disambiguation is context.
Doesn't XML's element structure gives you all the context machinery you need? If, for example, example.com wanted to extend the format with two new elements, let them do so in their own package/container element *named* after their DNS. Something like:
<com.example.NS.2003.Syndication.ECoolStuff> <amount> </com.example.NS.2003.Syndication.ECoolStuff>
[KellanElliottMcCrea] So far, any proposed extension to RSS that used nested elements has been a dismal failure in terms of uptake. Perhaps, they add even more complexity than namespaces?
[TimothyAppnel] I understand the concern of namespaces = complexity a wee bit. Long ago I thought the same thing when I first saw them, however my view has changed dramatically, so I really disagree that the "complexities" outweight the benefits. In fact I feel quite the opposite. XML namespaces provide trememendous benefit. They provide a clear and effective way of definitively adding tags without collisions or modification of the "core" syntax. Any worthwhile XML parser can automatically understand namespaces and deal with the tags. I've written code that had to be namespace-aware. While it took a bit for me to get my head around them, once I did they were not that bad; they made handling and identifying unknown elements quite straightforward.
[MattMower RefactorOk] Sean, maybe you can summarise some of the points about namespaces from the discussion that raged recently across xml-dev? I feel there were good points made but I lack the necessary expertise to summarise them myself.
[KellanElliottMcCrea] Please do. I've written several RSS parsers, and found namespaces to be wonderful and straightforward, but I'm also not an XML geek, so perhaps I'm missing something.
[SeanMcGrath RefactorOk] OK. My take on namespaces: http://www.itworld.com/nl/xml_prac/04112002/. Joe English's classification of the problems Namespaces can cause is worth a read. See "a plea for sanity" section : http://lists.xml.org/archives/xml-dev/200204/msg00170.html. Some of the horrid intertwinglements between namespaces and XML Schema: http://www.xml.com/pub/a/2001/08/22/deviant.html.
I know its a lost cause so I will shut up now:-) Given the inevitable that namespaces will be used, can I make a plea for extreme caution and restraint when it comes to namespaces? Most of the problems I see with namespaces manifest themselves in downstream processing (re-arranging XML tree structures and re-serializing, XPath'ing fragments etc.). For applications that are only concerned with read-side XML processing, the problems aren't as noticeable. Maybe Echo applications will all be read-side. I doubt it and would caution that the namespace stuff, unless checked at this stage, will cause grief downstream.
[AaronSw, RefactorOk] I think namespaces should be allowed; for simplicity, all the terms we define should be in a single namespace. In that way only people doing something proprietary or experimental will have to use them. (Or if the Echo Project dies for some reason and standardization of terms goes someplace else.)
[SeanConner, RefactorOk] Isn't this what Dave Winer and the whole FunkyFeeds thing is about? Unecessary use of XML namespaces? Because you know, he did include everything for a feed in a single namespace.
[JonathanSmith] Time marches on, and, perhaps, Namespace Routing Language may help resolve this issue?
[RahulDave] How are we going to represent HTML inclusion in Echo content if we don't allow for namespaces? On Infoset vs XML syntax (see InfoSetDiscussion), why not define the Infoset in XML syntax. Using DTD?XML Schema, even. I mean for validation, rather than for documentation. Once a precise documentation of one representation can be achived, one can come out of the woodwork with different equivalent carry's: Echo in RSS3, in SOAP, in RFC822, whatever is appropriate to an apps consumption and production. Obviously, the Echo XML syntax ought to be the meeting point for interop.
[ChrisWilper] Allow namespaces. It seems necessary if we want to support straight XML inclusion of XHTML. Also, I don't see a problem with directly using qualified DublinCore items, either. If people are set against putting dc in the serialization, then I would suggest at least that the spec define mapping to the DublinCore concepts that are applicable. It seems dumb not to leverage existing concepts if they are appropriate and well-defined.
[JimDriscoll, RefactorOk] Java-style element names? All you're doing there is kludging another namespace system in. I'd agree with the use of XML namespaces. While they do make XPath paths much more verbose - which I consider to be a failing of XPath if the context already sets a default namespace - they do actually make it much easier to pop out the data that you want. Also, please remember that if namespaces are provided - and allowed - that doesn't mean they necessarily have to be used. I'd also suggest having more than one namespace should not be discounted out-of-hand; if there are clearly separate subsets of the XML format that could conceivably exist on their own - and right now I can't think of one - then they should have their own namespace.
[KenMacLeod] I'm not as much a user of XPath and XSLT, though I thought they were "better" at namespaces than SAX and DOM (having been developed after XML Namespaces), but I know that several SAX and DOM bindings are artificially complex and archaic in their support of namespaces. I recognize that doesn't have much effect to the argument, because we're stuck with these implementations, but the problem is not as much technical as it is momentum.
[DiegoDoval, RefactorOk] I agree with Aaron: namespaces should be supported, but a complete baseline spec for Echo would mean that their use is limited to future extensions, proprietary extensions, and experimentation.
[ChristianRomney] Namespaces should be supported. If this is to be an XML-based format, then wholehearted support of namespaces should be the case. No one can see every possible future need at design time. Disallowing the use of namespaces will create more problems in the long run and not allow this work to be extended as easily or cleanly as it could be with namespaces.
<com.example.NS.2003.Syndication.ECoolStuff> <amount> </com.example.NS.2003.Syndication.ECoolStuff>are well-intentioned but ugly as hell to read.
[PhilWolff, RefactorOk] Are namespaces sufficient to enable a ComponentBlog, with packages of structured data? I'm interested in systems that provide ad hoc namespace autodiscovery, rendering, editing, storage, and syndication.
Strong disagreement on adding namespaces.
Does anyone have a reason to add namespace support, other than feeling they should?
<com.example.ns.tagname> <amount> </com.example.ns.tagname>
are only as ugly as you want them to be - certainly no uglier than a document litered with QNames and URI refs in attributes. And if this is a kluge, I'll take it over tunneling URIs through XML any day.
Here's the thing: Namespaces are not XML - thus supporting them isn't a requirement to support XML. They don't 'play nice' with non-namespaced XML (due to default namespaces). As a result it's hard to make their use 'rare' - namespaces are zero sum in athe sense that you can't be half-hearted about using them. By contrast, not using namespaces in Echo syntax does not stop people using namespaced XML inside feeds. They're not useful to cover off missed design time decisions, since they're not an extensibility mechanism they're a firewalling mechanism - name partitioning is not evolution by extension (XML is the real extensibility mechanism). Namespaces can't be used to safely extend vocabularies in any case - they can't be versioned and don't carry processing information (they're just Name Spaces after all). That they complicate XML processing and toolsets (as Sean points out, and he's not the only one) can hardly be disputed.
And adding extra constraints on top of namespaces won't work, it'll only take one provider to break all that (but if we could reach agreement on eliminating default namespaces, that would be a huge step forward...
The purpose of namespaces is twofold. First and formeost to stop name clashes - they achieve that, but at some cost given that there are other ways to do the same thing on the cheap - for example you can embed DC in HTML without using the DC namespace. Second as a way of naming things using URIs - RDF serialization was a usecase for namespaces.
Funny, my reaction is exactly opposite to Timothy's. When I saw them first I though they were a great idea, but exposure to them over the last 4 years has left me stone cold, particulary in using XML to integrate information sources (which is really what they're supposed to be good at).
Sorry folks, this Emperor has no clothes. But note that I'm not asking to stop any namespaced XML going through an Echo feed. If someone else wants to push namespaced XML thru Echo or add vocabularies via namespaces, nothing I've said here stops them.
[BillDehora] If there's a consensus to be reached I suspect it'll be around Diego's suggestions.
[DareObasanjo] I agree with Aaron and Diego. One of the primary driving forces behind starting Echo as a syndication format effort was the need for adding extensibility to the syndication format through XML namespaced modules and being able to include Echo messages as a payload in other XML message formats like SOAP. If Echo does not support namespaces because of religious dislike of namespaces then it will be a crippled format not worth implementing or supporting.
[SeanMcGrath RefactorOk] I'd just like to note that my dislike of namespaces is based on technical arguments not religious ones. Also, I disagree with the notion that utilising namespaces for modularity/extensibility is somehow mandatory in today's world. It isn't.
[PhilWolff RefactorOk] Sean, namespaces are well defined and there tools for them. Isn't that important for implementation and adoption? Is there an alternative, functionally equivalent, superior protocol/spec?
[AsbjornUlsberg, RefactorOk] If we, in 2003, are going to define a format based on XML, it's extremely stupid to not support namespaces. Namespaces are the standard way to add extensibility to XML documents, and their support is widespread and good. If you have technical arguments against namespaces, then you haven't worked with the right tools, imho. Tools with bad or no namespace support are bad tools, and should be exchanged with other tools. Because there are tools which supports namespaces in a very good manner, and there are no good reasons for not using them (and rather using the broken ones).
[BillDehora] Hmm, I'm unconvinced. The only thing namespaces 'extends' is XML itself (by changing it allow tunneling of URIs as element names). And if anyone has a good explanation of how namespaces can be used to extend a vocabulary I'm all ears - as far as I know, all namespaces can do is partiton vocabularies, not extend them. The argument from tools is easily refuted - tools are a third order effect and don't explain why namespaces should be supported in the first place. So please, why is not supporting namespaces, 'stupid' - or is that just meant to be taken as writ?
[AsbjornUlsberg, RefactorOk] You might take it as a writ, but it isn't. Really. When namespaces extend XML, they will also extend Echo. Look at it practically. When you parse an Echo feed, you can chose to select only nodes (and/or values of these nodes) within a certain namespace, e.g. the Echo namespace. This way you support the basic Echo feed. When or if this Echo feed contains extension nodes (mainly attributes and elements, but also values of base-Echo-nodes), these nodes are prefixed with a foreign namespace. What this namespace meens can be explained by someone completely different from the Echo Work Group. These nodes can be looked upon as plugins to the Echo feed itself, and don't necessarily have to be understood by all Echo-enabled tools.
All Echo-enabled tools must understand everything within the Echo namespace, but even in this scope we can define optional elements, attributes and the interpretation of them. E.g. fetching of external resources through the "src" or "href" attributes can be made optional. Just as an example. People might want to smack in an SVG image inline in a feed, and if we don't plunge a namespace onto "our" Echo nodes, it will be kinda messy. This SVG image doesn't have to be supportet by aggregators, but everything else has to. How would aggregators differantiate if they don't support namespaces because Echo doesn't?
Are you saying that namespaces should be disallowed in Echo entirely, so that all inline content also has to be namespace-less? E.g. all namespace-declarations of exisiting SVG-images, XHTML-documents, other XML-documents etc., has to be stripped away to be allowed inside an Echo feed at all? Then, aggregators have to check every node in the feed to see if they understand it, instead of adding support namespace by namespace. I think supporting namespaces is so easy that I can't see any drawbacks with it, especially considering all the advantages.
[JeremyGray] Sean, I have to disagree with your position on this subject. Numerous capable tools exist which account for your implementation concerns about namespaces, and 2003 offers little excuse for not putting such tools to use. Further, a number of the examples on the web pages you reference demonstrate usages which are far from best practices:
e.g. expecting that the <child /> element in
<ex:parent xmlns:ex="http://www.example.org"> <child /> </ex:parent>
is in the ex-prefixed namespace, when either
<ex:parent xmlns:ex="http://www.example.org"> <ex:child /> </ex:parent>or
<parent xmlns="http://www.example.org"> <child /> </parent>are simpler, more sensible, and match intent.
While your presented alternative would make little difference to software systems it would repeatedly kick sand in the face of the ViewSourceClan. <com.example.NS.2003.Syndication.ECoolStuff>, for example, is not going to benefit adoption.
[JeremyGray] Point taken, and, after some time away from the keyboard, updated. I was in a pretty cheeky mood this morning. All fixed now.