On Wednesday, 29 June 2016 at 12:06:23 UTC, Lodovico Giaretta
wrote:
the idea is that if we have a good, modular, extendable XML
library, then we can build everything on top of it as separate
projects. This is because one person cannot maintain all the
possible extensions (XPath, XSD, JAXB, XQu
On Tuesday, 28 June 2016 at 12:14:40 UTC, Nikolay wrote:
DOM - Any plans for Xpath?
DTD check - What about XSD? XSD is more popular now.
Also it would be nice to have something like JAXB
(automatically bind and map DLang struct/classes to/from XML).
But it may be part of next iteration or pro
On Thursday, 23 June 2016 at 20:04:26 UTC, Lodovico Giaretta
wrote:
-- Brace yourself: a very long post is coming --
What is planned for the near future?
- When the DOM classes will be usable (even if not 100%
complete) I will start working on a DOM parser to build them
from the source;
- DTD
On 6/28/16 4:04 AM, Lodovico Giaretta wrote:
On Monday, 27 June 2016 at 22:36:36 UTC, Martin Nowak wrote:
On 06/25/2016 10:33 PM, Lodovico Giaretta wrote:
But your idea about a stack keeping all the context informations is
quite valuable, given that some validations need them (e.g. checking
tha
On Monday, 27 June 2016 at 22:36:36 UTC, Martin Nowak wrote:
On 06/25/2016 10:33 PM, Lodovico Giaretta wrote:
But your idea about a stack keeping all the context
informations is quite valuable, given that some validations
need them (e.g. checking that all prefixes have been declared,
and retri
On 06/25/2016 10:33 PM, Lodovico Giaretta wrote:
>
> But my implementation does not maintain the state of the parents, so you
> can't get any info about the parent from the children, unless you use
> exit() (in which case, you can get the parent's name from the closing tag).
>
> But your idea abo
On Saturday, 25 June 2016 at 20:32:33 UTC, Walter Bright wrote:
Thank you for your hard work on this important project.
Please ensure that it has a range interface - a range is used
as input.
You mean that the document source may be a range?
In that case, I already implemented a lexer that w
On Saturday, 25 June 2016 at 20:16:09 UTC, Steven Schveighoffer
wrote:
When I had the gumption to try and make an XML parser range,
the idea I had was to have the current element's tag and
attributes, all parent elements' tags and attributes, and the
currently parsed entity inside the element.
On 6/23/2016 1:04 PM, Lodovico Giaretta wrote:
One month after the official GSoC start, I want to share with you what's in
std.experimental.xml and what will hopefully be there
Thank you for your hard work on this important project.
Please ensure that it has a range interface - a range is used
On 6/25/16 12:26 PM, Lodovico Giaretta wrote:
On Saturday, 25 June 2016 at 15:59:40 UTC, Jacob Carlborg wrote:
Any range API, or plan for?
Hi,
I'm definitely going to provide a wrapper around the Cursor API, that
will provide InputRange access to all the children of the current node
(this way
On Saturday, 25 June 2016 at 15:59:40 UTC, Jacob Carlborg wrote:
Any range API, or plan for?
Hi,
I'm definitely going to provide a wrapper around the Cursor API,
that will provide InputRange access to all the children of the
current node (this way the tree structure is maintained). I plan
t
On 23/06/16 22:04, Lodovico Giaretta wrote:
What is working?
- Four lexers are provided to abstract different kinds of input from the
other layers, providing different speed characteristics;
- The parser splits the document into nodes, doing most of the hard work;
- A cursor sits on top of the p
-- Brace yourself: a very long post is coming --
Hi,
One month after the official GSoC start, I want to share with you
what's in std.experimental.xml and what will hopefully be there.
If you have any question/improvement or anything to say, just
leave a comment here or an issue on GitHub
(ht
13 matches
Mail list logo
