Thank you for all the answers!
Stefaan.
--
http://mail.python.org/mailman/listinfo/python-list
stefaan wrote:
>> All of these are grammar-specifications that allow you to define the
>> structure of your XML-documents with more constraints.
>
> Ok, I should have foreseen the schema checker answer...my point really
> is that
> yacc can do even more than just checking the conformance to a gra
> Don't you think the lex/yacc combo is complex even in anything in
> real-life?
If real-life means: C++, then yes, it is impossible :)
If real-life means: some domain specific language, then it is ok.
>The "XML tree simplification implementations" (as Elementtree
> can be considered) has other co
Diez B. Roggisch wrote:
> What you are after then is the usage of a validating parser, not just
> well-formed XML-documents.
>
> I'm not sure where element-tree stands regarding this, but I think 4suite
> offers DTD, W3C-Schema and Relax-NG support.
So he's effectively written his own validating
stefaan napisał(a):
> No schema checker can take this specification and simply output "22".
> XSLT might be able to implement it, but it is complex for anything
> real-life. Elementtree can immediately give me the concrete syntax
> tree,
> but any semantic actions have to be implemented during a
>
> All of these are grammar-specifications that allow you to define the
> structure of your XML-documents with more constraints.
Ok, I should have foreseen the schema checker answer...my point really
is that
yacc can do even more than just checking the conformance to a grammar.
It also allows me t
Diez B. Roggisch napisał(a):
> I'm not sure where element-tree stands regarding this, but I think 4suite
> offers DTD, W3C-Schema and Relax-NG support.
This varies depending on implementation. As Fredrik Lundh's original
implementation is based on expat parser, it has no ability to check
anything
stefaan wrote:
>> Elementtree isn't lex. You are comparing apples and oranges here. Lex
>> tokenizes, yacc creates trees. Both of is covered in XML itself - it's
>> defined the tokenization and parsing, built into elementtree. So,
>> elemnttree is lex _and_ yacc for XML. And if your language is wr
stefaan a écrit :
>> Elementtree isn't lex. You are comparing apples and oranges here. Lex
>> tokenizes, yacc creates trees. Both of is covered in XML itself - it's
>> defined the tokenization and parsing, built into elementtree. So,
>> elemnttree is lex _and_ yacc for XML. And if your language is
> Elementtree isn't lex. You are comparing apples and oranges here. Lex
> tokenizes, yacc creates trees. Both of is covered in XML itself - it's
> defined the tokenization and parsing, built into elementtree. So,
> elemnttree is lex _and_ yacc for XML. And if your language is written in
> XML, that
stefaan wrote:
> Thank you Diez for answering.
> As far as I can see, it more or less corresponds to what I have.
>
> But my question was perhaps more this:
>
> "If elementtree is "lex", what is "yacc" ? "
Elementtree isn't lex. You are comparing apples and oranges here. Lex
tokenizes, yacc cre
Thank you Diez for answering.
As far as I can see, it more or less corresponds to what I have.
But my question was perhaps more this:
"If elementtree is "lex", what is "yacc" ? "
--
http://mail.python.org/mailman/listinfo/python-list
stefaan schrieb:
> Hello,
>
> I have recently had to deal with an XML-based
> programming language. (The programs are
> generated programmatically.)
>
> XML leads to a "two-level" parsing problem: first
> parse the xml into tokens, then parse the tokens
> to grasp their meaning (based on the sema
13 matches
Mail list logo
