xml:lang in SXML
The attribute xml:lang is not correctly specified in section Example according to the SXML specification. In fact, the specification is unclear how to do this: a quote from the section Annotations:
Genuine, semantic attributes provide ancillary description of the corresponding XML element, e.g., <weight units='kg'>16</weight> On the other hand, attributes such as xmlns, xml:prefix, xml:lang and xml:space are auxiliary, or being used by XML itself. The XML Recommendation distinguishes auxiliary attributes by their prefix xml. SXML groups all such auxiliary attributes into a @-tagged list inside the attribute list.
indeed, actually the first google hit seems to be a common lisp implementation of the process and not a scheme implementation. in fact, the syntax as described works perfectly fine in almost all lisps. its probably just schemers feeling superiour over other lisps again. --126.96.36.199 (talk) 15:09, 9 June 2010 (UTC)
Sufficient, but not necessary
The article currently says:
Since an SXML document and its nodes are S-expressions, they can be used for representing a Scheme program. For making this possible, it is necessary (and sufficient) that the first member of every list contained in the SXML tree is a function.
The above assertion does not take into account that Scheme (like other dialects of Lisp) supports macros. The following macro would make it unnecessary for attribute names to be bound to functions:
(define-syntax @ (syntax-rules () ((_ . rest) (quote rest))))
Thus, though binding every symbol that appears as a list-head to a function is one way to make an SXML document be a Lisp program (ie, it is sufficient), it isn't the only way (it is not necessary). —Preceding unsigned comment added by 188.8.131.52 (talk) 14:21, 13 November 2008 (UTC)
User:Tony Sidaway has undone a whole chapter based on the following reason:
- Actually this is just somebody's personal opinion and doesn't for instance take into account backtracking techniques
However, keeping a stack of the walked parent nodes plus their index relative to each parent is a backtracking technique, and the only one feasible if executing XPath expressions which might not be static (i.e. depend on variables or on XPath expressions in the document itself). This information is not a point of view.
Further, the chapter doesn't only refer to the backtracking problem, but also to list iterating. In a vector, accessing the nth element is o(1), because you can simply "jump" to it. In a linked list, accessing the nth element is o(n) , because you must "walk" the list until the requests element. This is, of course, a performance hit when accessing nodes by index for long documents (not necessarily for deeply nested ones, i.e. in a tree of vectors, a child node is a vector pointed to by its parent). This information is not a point of view.
The last paragraph refers to how SXML and alikes are suited for SAX-like processing, because if you must backtrack to access the parent or previous sibling nodes, you lose the ability to grab a piece of a document by itself and be able to walk back to the root node, like you can using DOM. Of course, DOM is memory intensive, but this section is about SXML shortcomings, not DOM's. This information might be a point of view. Suitability here refers only to performance.
I suggest you don't delete this chapter, rather correct it if necessary. Otherwise the article itself has not NPOV because it doesn't state the (obvious) disadvantages of this XML representation, which is clearly a significant view. Don't get me wrong, I still use SXML and XML-S representations as my preferred tools for XML handling in Lisp (because of performance, mostly), but certainly not the only ones. DOM can be quite handy and SOM too (through MSXML using COM in Win32).
PS: It might seem that I contradict myself when I say I use this kind of XML representation for performance reasons. Indeed, most of my processing is either sequential or tree-traversal bound, which means I don't need a full XML Infoset. Further, list processing is much more readable and easy to code in a Lisp (which actually means list processing) than vector processing, without much more overhead since I rarely access a node by its index.
- This page isn't for discussing the merits of SXML, nor is the article for including unsourced assessments of SXML. I don't necessarily disagree with you on the merits, but without a reliable source the above argument, and that which I had removed from the article, are original research. --TS 17:31, 6 December 2009 (UTC)
- You're right, I'm sorry. I'm not going to enter a holy war on this, but I must say that most content on Wikipedia is original research. However, since the policy is to avoid it, I must agree and conclude (once again) that you're right. Please do with that section as you see fit. 184.108.40.206 (talk) 16:22, 7 December 2009 (UTC)
- What I propose to do is leave it as it is and try to find sources. --TS 16:56, 7 December 2009 (UTC)
- I didn't look quite well at SXML the first time I read it, but since it permits annotations (which can contain a link to the parent/owner node), the only real shortcomming is the list versus vector implementation when fetching nodes directly by position (which I believe to be a rare condition). I don't believe there is any source for this, but I invite you to delete all but the second paragraph, and mark the second paragraph as needing citation. You were right from the start, my apologies. 220.127.116.11 (talk) 17:37, 5 January 2010 (UTC)
In the "Motivation" section somebody has added "citation needed" to the statement, that neither XPath, XSLT nor XQuery are general-purpose programming languages. None of those are Turing complete so it's pretty obvious that they aren't "sufficient for implementing complete applications". They weren't intended to write whole applications in them, just to query or transform XML. —Preceding unsigned comment added by 18.104.22.168 (talk) 10:25, 5 January 2010 (UTC)
I removed the mention of media type in the infobox. There is no MIME type text/sxml registered, according to http://www.iana.org/assignments/media-types/text/index.html NormanGray (talk) 16:33, 23 October 2011 (UTC)