Thread: [Vtd-xml-users] xerces discussion on VTD

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

interesting thread, thought you might want to comment if you've not seen it:

http://www.nabble.com/VTD-XML-thoughts--tf2816326.html

Thanks. It would take sometime to take VTD seriously...
Given that DOM and SAX are so bad for so long, people
have literally got used to them... and sometime had a tough
time getting out of the "cave."
----- Original Message ----- 
From: "Paul Tomsic" <pt...@gm...>
To: <vtd...@li...>; <cra...@co...>
Sent: Wednesday, January 17, 2007 6:17 AM
Subject: xerces discussion on VTD

> interesting thread, thought you might want to comment if you've not seen 
> it:
>
> http://www.nabble.com/VTD-XML-thoughts--tf2816326.html
> 

--- Jimmy Zhang <cra...@co...> wrote:

> Thanks. It would take sometime to take VTD
> seriously...
> Given that DOM and SAX are so bad for so long,
> people
> have literally got used to them... and sometime had
> a tough
> time getting out of the "cave."

It is true, however, that VTD-XML as well as any other
tools has its optimal use cases, and limits.
I think it is useful to be clear about both benefits
(compact representation, efficient just-in-time
extraction if only parts of content are needed, fast
serialization likewise if modifications are small) and
limitations.

There are really 2 major limitations I think:

(a) It does not (and probably will not) handle DTDs:
validation is not the problem (it could be
implemented), but entities are, and perhaps things
like attribute defaulting and normalization. This may
be problematic for document-centric approaches, but
usually is not for data-centric (like SOAP messages
etc)
(b) Namespace handling is not very complete, nor
efficient; this because the way namespaces work is
somewhat conflicting with the way VTD-XML does its
processing, to obtain high speed. So I am not sure if
it should be used for documents with namespaces.

There are still many use cases where neither above is
a problem: but there are also cases where it is.
Clearly understanding limitations and benefits, and
choosing right tools based on this is essential.

-+ Tatu +-

____________________________________________________________________________________
Have a burning question?  
Go to www.Answers.yahoo.com and get answers from real people who know.

See my comments below

----- Original Message ----- 
From: "Tatu Saloranta" <cow...@ya...>
To: "Jimmy Zhang" <cra...@co...>; "Paul Tomsic" <pt...@gm...>; 
<vtd...@li...>
Sent: Wednesday, January 17, 2007 10:48 AM
Subject: Re: [Vtd-xml-users] xerces discussion on VTD

> --- Jimmy Zhang <cra...@co...> wrote:
>
>> Thanks. It would take sometime to take VTD
>> seriously...
>> Given that DOM and SAX are so bad for so long,
>> people
>> have literally got used to them... and sometime had
>> a tough
>> time getting out of the "cave."
>
> It is true, however, that VTD-XML as well as any other
> tools has its optimal use cases, and limits.
> I think it is useful to be clear about both benefits
> (compact representation, efficient just-in-time
> extraction if only parts of content are needed, fast
> serialization likewise if modifications are small) and
> limitations.
>
> There are really 2 major limitations I think:
>
> (a) It does not (and probably will not) handle DTDs:
> validation is not the problem (it could be
> implemented), but entities are, and perhaps things
> like attribute defaulting and normalization. This may
> be problematic for document-centric approaches, but
> usually is not for data-centric (like SOAP messages
> etc)

DTD seems to have been depleted somewhat, e.g.
in SOAP, various types of industry specific vocabularies,
RDFs... XPath and XQuery doesn't even have the notion
of DTD anymore...

> (b) Namespace handling is not very complete, nor
> efficient; this because the way namespaces work is
> somewhat conflicting with the way VTD-XML does its
> processing, to obtain high speed. So I am not sure if
> it should be used for documents with namespaces.
>

The name space handling is quite efficient... most cases
I have not seen much difference at all... as to the completion
part, I have two thoughts, one is that the namespace spec
itself has issues, the second is that adding complete support
of it should not be difficult nor inefficient...

> There are still many use cases where neither above is
> a problem: but there are also cases where it is.
> Clearly understanding limitations and benefits, and
> choosing right tools based on this is essential.
>

I don't know why some kept thinking VTD is compressed
DOM...does it look like compressed DOM to you?

> -+ Tatu +-
>
>
>
>
>
> ____________________________________________________________________________________
> Have a burning question?
> Go to www.Answers.yahoo.com and get answers from real people who know.
> 

--- Jimmy Zhang <cra...@co...> wrote:

> > There are really 2 major limitations I think:
> >
> > (a) It does not (and probably will not) handle
> DTDs:
> 
> DTD seems to have been depleted somewhat, e.g.
> in SOAP, various types of industry specific
> vocabularies, RDFs... XPath and XQuery doesn't even
have the
> notion of DTD anymore...

Right, I am not arguing whether it is very relevant or
not,
just pointing out that for cases where it is
(minority,
perhaps?), it is a limitation.

> > (b) Namespace handling is not very complete, nor
> > efficient; this because the way namespaces work is
> > somewhat conflicting with the way VTD-XML does its
> > processing, to obtain high speed. So I am not sure
> if
> > it should be used for documents with namespaces.
> 
> The name space handling is quite efficient... most
> cases
> I have not seen much difference at all... as to the

Well, let me put it this way: since it is done
on-demand,
its effects accumulate. It obviously does not add
overhead
during parsing stage (which is good), but it seems to
me
that processing done on-demand is much more extensive
than if it was incrementally computed during parsing.
Perhaps better way to put it is that in general VTD
minimizes
up-front costs, by adding some higher on-demand costs.
My favourite example is text access: if you must
access content
as Strings, it is little bit slower with VTD, since it
has
to decode content twice in those cases (first during
parsing,
to find indexes/offsets; second time when constructing
the
String). The same pattern is used extensively, and I
would
consider architectural/design decision.

Anyway, I do not think performance aspects are the
limiting
factor at this point; but it might become one if
non-conformant
cases were handled. Specifically, whereas parsing in
general is
checking for well-formedness constraints, this does
not
cover namespace validity checking. Attributes ns1:a
and
ns2:a may be duplicates, and this is not checked
at this point (as far as I know). If those were
checked during
parsing (as is the case for straight duplicate
checks),
parser would either have to keep namespace binding
state
(which might not be too bad), or dynamically derive
bindings (as is now done on-demand).
Similarly, checks for unbound namespaces should be
added,
if namespace-conformance was to be completed.

> completion
> part, I have two thoughts, one is that the namespace
> spec
> itself has issues, the second is that adding

It is bit complicated to implement, and not
necessarily
defined in optimal way. But at least it has no
ambiguities that I know of.

> complete support
> of it should not be difficult nor inefficient...

If so, I am sure this will be done in future! ;-)

...
> > Clearly understanding limitations and benefits,
> and
> > choosing right tools based on this is essential.
> >
> 
> I don't know why some kept thinking VTD is
> compressed
> DOM...does it look like compressed DOM to you?

No, I think that is wrong. It may be because some
people nowadays think any XML tree representation
is DOM. That's just not right.

-+ Tatu +-

____________________________________________________________________________________
Expecting? Get great news right away with email Auto-Check. 
Try the Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html 

i agree on the getting out of the cave, per se.
python does a great job of handling XML via it's etree implementation,
and there's really not much competition for it.  since java's got a
different xml implementation around every corner, then it's easy to
dismiss something other than one's that ppl recognize (SAX/DOM/etc)

i'd love to see VTD support XSD's, specifically schema validation, and
the ability to determine backward compatibility within an XSD.  I've
yet to find something that can determine if an XSD is backward
compatible or not.

On 1/17/07, Jimmy Zhang <cra...@co...> wrote:
> Thanks. It would take sometime to take VTD seriously...
> Given that DOM and SAX are so bad for so long, people
> have literally got used to them... and sometime had a tough
> time getting out of the "cave."
> ----- Original Message -----
> From: "Paul Tomsic" <pt...@gm...>
> To: <vtd...@li...>; <cra...@co...>
> Sent: Wednesday, January 17, 2007 6:17 AM
> Subject: xerces discussion on VTD
>
>
> > interesting thread, thought you might want to comment if you've not seen
> > it:
> >
> > http://www.nabble.com/VTD-XML-thoughts--tf2816326.html
> >
>
>
>

--- Paul Tomsic <pt...@gm...> wrote:

...
> i'd love to see VTD support XSD's, specifically
> schema validation, and
> the ability to determine backward compatibility

I don't think it absolutely must be implemented by VTD
itself however. But it should be possible to integrate
something like Multi-Schema Validator, to validate VTD
trees (against W3C Schema, or Relax NG).

> within an XSD.  I've
> yet to find something that can determine if an XSD
> is backward
> compatible or not.

Likewise, this sounds like task for a schema
processing tool, and writing one is probably even more
work than writing efficient parsers. I think
separation of concerns is good.

-+ Tatu +-

____________________________________________________________________________________
Get your own web address.  
Have a HUGE year through Yahoo! Small Business.
http://smallbusiness.yahoo.com/domains/?p=BESTDEAL

Can Woodstox's XSD implementation be readapted as a general purpose
XSD validator??
Also how is the name of "woodstox" created? Does it have anything to
do with the musical festival? :)
----- Original Message ----- 
From: "Tatu Saloranta" <cow...@ya...>
To: "Paul Tomsic" <pt...@gm...>; "Jimmy Zhang" <cra...@co...>
Cc: <vtd...@li...>
Sent: Wednesday, January 17, 2007 10:56 AM
Subject: Re: [Vtd-xml-users] xerces discussion on VTD

> --- Paul Tomsic <pt...@gm...> wrote:
>
> ...
>> i'd love to see VTD support XSD's, specifically
>> schema validation, and
>> the ability to determine backward compatibility
>
> I don't think it absolutely must be implemented by VTD
> itself however. But it should be possible to integrate
> something like Multi-Schema Validator, to validate VTD
> trees (against W3C Schema, or Relax NG).
>
>> within an XSD.  I've
>> yet to find something that can determine if an XSD
>> is backward
>> compatible or not.
>
> Likewise, this sounds like task for a schema
> processing tool, and writing one is probably even more
> work than writing efficient parsers. I think
> separation of concerns is good.
>
> -+ Tatu +-
>
>
>
>
> ____________________________________________________________________________________
> Get your own web address.
> Have a HUGE year through Yahoo! Small Business.
> http://smallbusiness.yahoo.com/domains/?p=BESTDEAL
> 

--- Jimmy Zhang <cra...@co...> wrote:

> Can Woodstox's XSD implementation be readapted as a
> general purpose
> XSD validator??

Woodstox only implements DTD support natively, Schema
and RNG are handled using other libraries.
For validation, it uses MSV (Sun Multi-Schema
Validator) as a plug-in, using a simple wrapper. That
is why I thought it actually might also make sense for
VTD. It may not be as fast as having native support,
but anyone doing validation should expected some
additional performance overhead (IMO).
Of course, it is possible to start with a plug-in, and
given more time, implement native support.

Actually, I still haven't finished up W3C Schema
integration, only RelaxNG integration. This because
Schema is bit more invasive, as it needs to accesss
attributes in elements (xsi:type, schemaLocation),
whereas RNG is more modular.

> Also how is the name of "woodstox" created? Does it
> have anything to
> do with the musical festival? :)

:-)

Kind of, and also, the character from Peanuts cartoon.
I think one of my co-workers suggested it, starting
from "Stax". I think another alternative someone
suggested was "Fastax".

-+ Tatu +-

____________________________________________________________________________________
We won't tell. Get more on shows you hate to love 
(and love to hate): Yahoo! TV's Guilty Pleasures list.
http://tv.yahoo.com/collections/265 

I am also wondering if anyone in this list has come across a case
where performance of WS implementation is important...
so far there seems bits and pieces of evidences, not really anything
concrete and real...any suggestions on where to collect those anecdotal
evidences...
----- Original Message ----- 
From: "Tatu Saloranta" <cow...@ya...>
To: "Jimmy Zhang" <cra...@co...>
Cc: <vtd...@li...>
Sent: Wednesday, January 17, 2007 12:19 PM
Subject: Re: [Vtd-xml-users] xerces discussion on VTD

> --- Jimmy Zhang <cra...@co...> wrote:
>
>> Can Woodstox's XSD implementation be readapted as a
>> general purpose
>> XSD validator??
>
> Woodstox only implements DTD support natively, Schema
> and RNG are handled using other libraries.
> For validation, it uses MSV (Sun Multi-Schema
> Validator) as a plug-in, using a simple wrapper. That
> is why I thought it actually might also make sense for
> VTD. It may not be as fast as having native support,
> but anyone doing validation should expected some
> additional performance overhead (IMO).
> Of course, it is possible to start with a plug-in, and
> given more time, implement native support.
>
> Actually, I still haven't finished up W3C Schema
> integration, only RelaxNG integration. This because
> Schema is bit more invasive, as it needs to accesss
> attributes in elements (xsi:type, schemaLocation),
> whereas RNG is more modular.
>
>> Also how is the name of "woodstox" created? Does it
>> have anything to
>> do with the musical festival? :)
>
> :-)
>
> Kind of, and also, the character from Peanuts cartoon.
> I think one of my co-workers suggested it, starting
> from "Stax". I think another alternative someone
> suggested was "Fastax".
>
> -+ Tatu +-
>
>
>
>
> ____________________________________________________________________________________
> We won't tell. Get more on shows you hate to love
> (and love to hate): Yahoo! TV's Guilty Pleasures list.
> http://tv.yahoo.com/collections/265
> 

Hi,

Paul Tomsic <pt...@gm...> writes:

> i'd love to see VTD support XSD's, specifically schema validation,

I think there will be problems similar to what one would encounter
implementing support for DTD. XML Schema has a number of places
where the document is modified, including default attribute and
element expansion, value normalization (e.g., removing of white-
spaces), etc.

Tatu Saloranta <cow...@ya...> writes:

> It does not (and probably will not) handle DTDs:
> validation is not the problem (it could be
> implemented), but entities are, and perhaps things
> like attribute defaulting and normalization. This may
> be problematic for document-centric approaches, but
> usually is not for data-centric (like SOAP messages
> etc)

=46rom my experience both use things like default attributes
and data normalization equally often. Also note that if
you are really into speed/space optimization for data-
centric applications then the way to go is to parse the
data directly into business objects rather than creating
a raw representation of XML. Also implementing validation
by generating schema-specific validators helps a lot, as
shown in this benchmark:

http://www.codesynthesis.com/projects/xsdbench/

hth,
-boris

--=20
Boris Kolpackov
Code Synthesis Tools CC
http://www.codesynthesis.com
Open-Source, Cross-Platform C++ XML Data Binding

It  can be done fairly well, default attribute is not very often used,
element expansion and value normalization can be done "virtually,"
and most of the useful features of XSD will be available,

then again, XSD is an incredible complex beast, the most useful ones
are, more often than not, the simpler ones...

> i'd love to see VTD support XSD's, specifically schema validation,

I think there will be problems similar to what one would encounter
implementing support for DTD. XML Schema has a number of places
where the document is modified, including default attribute and
element expansion, value normalization (e.g., removing of white-
spaces), etc.
----- Original Message ----- 
From: "Boris Kolpackov" <bo...@co...>
To: <vtd...@li...>
Cc: "Tatu Saloranta" <cow...@ya...>
Sent: Wednesday, January 17, 2007 11:46 PM
Subject: Re: [Vtd-xml-users] xerces discussion on VTD

> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share 
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

--------------------------------------------------------------------------------

> _______________________________________________
> Vtd-xml-users mailing list
> Vtd...@li...
> https://lists.sourceforge.net/lists/listinfo/vtd-xml-users
> 

Hi Jimmy,

Jimmy Zhang <cra...@co...> writes:

> default attribute is not very often used

We have a fairly large repository of real-world schemas and the
analysis as well as my experience shows exactly the opposite:
default attribute values are very widely used. Also the paper
called "Analysis of XML schema usage"[1] arrives at the same
conclusion on page 26.

[1] http://homepages.cwi.nl/~ralf/xml05/paper.pdf

hth,
-boris

--=20
Boris Kolpackov
Code Synthesis Tools CC
http://www.codesynthesis.com
Open-Source, Cross-Platform C++ XML Data Binding

Thanks! I will take a look and post more of my thoughts later...
----- Original Message ----- 
From: "Boris Kolpackov" <bo...@co...>
To: "Jimmy Zhang" <cra...@co...>
Cc: <vtd...@li...>
Sent: Thursday, January 18, 2007 1:09 AM
Subject: Re: [Vtd-xml-users] xerces discussion on VTD

A few things about this default element/attribute val feature in schema at
the moment

1. This feature is not really about validation
2.  it seems more like a way to modify the XML structure.

do you see this as an essential feature of XSD?

----- Original Message ----- 
From: "Jimmy Zhang" <cra...@co...>
To: "Boris Kolpackov" <bo...@co...>
Cc: <vtd...@li...>
Sent: Thursday, January 18, 2007 11:20 AM
Subject: Re: [Vtd-xml-users] xerces discussion on VTD

> Thanks! I will take a look and post more of my thoughts later...
> ----- Original Message ----- 
> From: "Boris Kolpackov" <bo...@co...>
> To: "Jimmy Zhang" <cra...@co...>
> Cc: <vtd...@li...>
> Sent: Thursday, January 18, 2007 1:09 AM
> Subject: Re: [Vtd-xml-users] xerces discussion on VTD
>
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share 
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Vtd-xml-users mailing list
> Vtd...@li...
> https://lists.sourceforge.net/lists/listinfo/vtd-xml-users
> 

--- Jimmy Zhang <cra...@co...> wrote:

> A few things about this default element/attribute
> val feature in schema at
> the moment
> 
> 1. This feature is not really about validation

Right. It is one of ill-defined features of W3C Schema
(IMO), and was probably added to make it easier to
transition from DTDs, as DTD allows attribute
defaulting. Thank god Schema didn't port over general
entities, though.

There's a term to describe result of Schema validated
document, with possible augmentations (PSVI,
Post-Schema-Validation Infoset?).

> 2.  it seems more like a way to modify the XML
> structure.
> 
> do you see this as an essential feature of XSD?

Although I can't answer for Boris, I assume it all
depends on use cases. For some use cases and users it
may, for others not.
But more than this, whether those use cases are core
use cases for VTD.

I have said this before, but I think there is value in
knowing exactly where and to whom VTD could add most
value. Whether it eventually gets used for wide-range
of tasks or not, there are some areas where it seems
more optimal than others. And from that one could ask
the question: "does Schema in general matter for [core
use cases]; and if it does, is attribute defaulting
used for them".

>From my perspective, VTD's main potential benefit is
its speed. But for many Schema-dependant use cases,
users do not care (or are ignorant).
I have seen enough developers write code where they
convert from Strings to JDOM trees and back, happily
using convenience methods to construct dynamic xpath
expression all over the place, that I honestly do not
think most developers care. Even by just properly
using existing tools they'd get significant
improvements.
For them, it all comes down to perceived simplicity of
API. Usually they are pretty happy when they see, say,
XOM, after using DOM for a while.

And then there are other use cases where performance
does matter, and people are willing to invest time in
understanding new tools and learning new APIs. That's
where solutions like VTD may come in handy.

-+ Tatu +-

____________________________________________________________________________________
Expecting? Get great news right away with email Auto-Check. 
Try the Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html 

There has been quite a few people saying that XML's many use case do
not involve schema.. Do you feel JDOM is easy use... I don't know because
while performance and memory can be measured, ease of use is usually a 
matter
of opinion (even religion)... my own take: there is not much in JDOM that is 
Java specific,
one can probably create some sort of C# DOM which retains the features of 
JDOM...
again, I am personally still seeking inputs on the core API of VTD-XML and 
my own
view on ease of use of VTD-XML is biased  ... :)

----- Original Message ----- 
From: "Tatu Saloranta" <cow...@ya...>
To: "Jimmy Zhang" <cra...@co...>; "Boris Kolpackov" 
<bo...@co...>
Cc: <vtd...@li...>
Sent: Monday, January 22, 2007 3:43 PM
Subject: Re: [Vtd-xml-users] xerces discussion on VTD

> --- Jimmy Zhang <cra...@co...> wrote:
>
>> A few things about this default element/attribute
>> val feature in schema at
>> the moment
>>
>> 1. This feature is not really about validation
>
> Right. It is one of ill-defined features of W3C Schema
> (IMO), and was probably added to make it easier to
> transition from DTDs, as DTD allows attribute
> defaulting. Thank god Schema didn't port over general
> entities, though.
>
> There's a term to describe result of Schema validated
> document, with possible augmentations (PSVI,
> Post-Schema-Validation Infoset?).
>
>> 2.  it seems more like a way to modify the XML
>> structure.
>>
>> do you see this as an essential feature of XSD?
>
> Although I can't answer for Boris, I assume it all
> depends on use cases. For some use cases and users it
> may, for others not.
> But more than this, whether those use cases are core
> use cases for VTD.
>
> I have said this before, but I think there is value in
> knowing exactly where and to whom VTD could add most
> value. Whether it eventually gets used for wide-range
> of tasks or not, there are some areas where it seems
> more optimal than others. And from that one could ask
> the question: "does Schema in general matter for [core
> use cases]; and if it does, is attribute defaulting
> used for them".
>
> From my perspective, VTD's main potential benefit is
> its speed. But for many Schema-dependant use cases,
> users do not care (or are ignorant).
> I have seen enough developers write code where they
> convert from Strings to JDOM trees and back, happily
> using convenience methods to construct dynamic xpath
> expression all over the place, that I honestly do not
> think most developers care. Even by just properly
> using existing tools they'd get significant
> improvements.
> For them, it all comes down to perceived simplicity of
> API. Usually they are pretty happy when they see, say,
> XOM, after using DOM for a while.
>
> And then there are other use cases where performance
> does matter, and people are willing to invest time in
> understanding new tools and learning new APIs. That's
> where solutions like VTD may come in handy.
>
> -+ Tatu +-
>
>
>
>
> ____________________________________________________________________________________
> Expecting? Get great news right away with email Auto-Check.
> Try the Yahoo! Mail Beta.
> http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html
> 

Yes, that can be done... the issue is whether that should be part
of the core API...

this is how you can do it

<test attr1= "a1" attr2="a2" />
Since VTD-XML offers a flat view of the tokens, once you 
get to the "test" element, corresponding to index value of 

i,  then if there are two attr names, the indices would be
i+1, i+3,  both of which has the token type of attr_name,
or attr_ns, and of the same depth as the token i....

once you have the index value for attr names, call 
vn.toString(i+1)
vn.toString(i+3)
will get you the string values...

----- Original Message ----- 
From: "Atzmon Hen-Tov" <at...@po...>
To: "Jimmy Zhang" <cra...@co...>
Sent: Monday, January 22, 2007 10:49 PM
Subject: RE: [Vtd-xml-users] xerces discussion on VTD

Re "core API", is there a way to get the names of all attributes on the
current element?
Suppose I don't know which attributes to expect...

-----Original Message-----
From: vtd...@li...
[mailto:vtd...@li...] On Behalf Of Jimmy
Zhang
Sent: Tuesday, January 23, 2007 6:42 AM
To: Tatu Saloranta; Boris Kolpackov
Cc: vtd...@li...
Subject: Re: [Vtd-xml-users] xerces discussion on VTD

There has been quite a few people saying that XML's many use case do
not involve schema.. Do you feel JDOM is easy use... I don't know
because
while performance and memory can be measured, ease of use is usually a 
matter
of opinion (even religion)... my own take: there is not much in JDOM
that is 
Java specific,
one can probably create some sort of C# DOM which retains the features
of 
JDOM...
again, I am personally still seeking inputs on the core API of VTD-XML
and 
my own
view on ease of use of VTD-XML is biased  ... :)

----- Original Message ----- 
From: "Tatu Saloranta" <cow...@ya...>
To: "Jimmy Zhang" <cra...@co...>; "Boris Kolpackov" 
<bo...@co...>
Cc: <vtd...@li...>
Sent: Monday, January 22, 2007 3:43 PM
Subject: Re: [Vtd-xml-users] xerces discussion on VTD

> --- Jimmy Zhang <cra...@co...> wrote:
>
>> A few things about this default element/attribute
>> val feature in schema at
>> the moment
>>
>> 1. This feature is not really about validation
>
> Right. It is one of ill-defined features of W3C Schema
> (IMO), and was probably added to make it easier to
> transition from DTDs, as DTD allows attribute
> defaulting. Thank god Schema didn't port over general
> entities, though.
>
> There's a term to describe result of Schema validated
> document, with possible augmentations (PSVI,
> Post-Schema-Validation Infoset?).
>
>> 2.  it seems more like a way to modify the XML
>> structure.
>>
>> do you see this as an essential feature of XSD?
>
> Although I can't answer for Boris, I assume it all
> depends on use cases. For some use cases and users it
> may, for others not.
> But more than this, whether those use cases are core
> use cases for VTD.
>
> I have said this before, but I think there is value in
> knowing exactly where and to whom VTD could add most
> value. Whether it eventually gets used for wide-range
> of tasks or not, there are some areas where it seems
> more optimal than others. And from that one could ask
> the question: "does Schema in general matter for [core
> use cases]; and if it does, is attribute defaulting
> used for them".
>
> From my perspective, VTD's main potential benefit is
> its speed. But for many Schema-dependant use cases,
> users do not care (or are ignorant).
> I have seen enough developers write code where they
> convert from Strings to JDOM trees and back, happily
> using convenience methods to construct dynamic xpath
> expression all over the place, that I honestly do not
> think most developers care. Even by just properly
> using existing tools they'd get significant
> improvements.
> For them, it all comes down to perceived simplicity of
> API. Usually they are pretty happy when they see, say,
> XOM, after using DOM for a while.
>
> And then there are other use cases where performance
> does matter, and people are willing to invest time in
> understanding new tools and learning new APIs. That's
> where solutions like VTD may come in handy.
>
> -+ Tatu +-
>
>
>
>
>
________________________________________________________________________
____________
> Expecting? Get great news right away with email Auto-Check.
> Try the Yahoo! Mail Beta.
> http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html
> 

------------------------------------------------------------------------
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
V
_______________________________________________
Vtd-xml-users mailing list
Vtd...@li...
https://lists.sourceforge.net/lists/listinfo/vtd-xml-users

Getting back to one of your early questions, we are thinking about a global
LIFO to the core API of VTD-XML, which can be used to record node
position...  

----- Original Message ----- 
From: "Atzmon Hen-Tov" <at...@po...>
To: "Jimmy Zhang" <cra...@co...>
Sent: Monday, January 22, 2007 10:49 PM
Subject: RE: [Vtd-xml-users] xerces discussion on VTD

Re "core API", is there a way to get the names of all attributes on the
current element?
Suppose I don't know which attributes to expect...

-----Original Message-----
From: vtd...@li...
[mailto:vtd...@li...] On Behalf Of Jimmy
Zhang
Sent: Tuesday, January 23, 2007 6:42 AM
To: Tatu Saloranta; Boris Kolpackov
Cc: vtd...@li...
Subject: Re: [Vtd-xml-users] xerces discussion on VTD

There has been quite a few people saying that XML's many use case do
not involve schema.. Do you feel JDOM is easy use... I don't know
because
while performance and memory can be measured, ease of use is usually a 
matter
of opinion (even religion)... my own take: there is not much in JDOM
that is 
Java specific,
one can probably create some sort of C# DOM which retains the features
of 
JDOM...
again, I am personally still seeking inputs on the core API of VTD-XML
and 
my own
view on ease of use of VTD-XML is biased  ... :)

----- Original Message ----- 
From: "Tatu Saloranta" <cow...@ya...>
To: "Jimmy Zhang" <cra...@co...>; "Boris Kolpackov" 
<bo...@co...>
Cc: <vtd...@li...>
Sent: Monday, January 22, 2007 3:43 PM
Subject: Re: [Vtd-xml-users] xerces discussion on VTD

> --- Jimmy Zhang <cra...@co...> wrote:
>
>> A few things about this default element/attribute
>> val feature in schema at
>> the moment
>>
>> 1. This feature is not really about validation
>
> Right. It is one of ill-defined features of W3C Schema
> (IMO), and was probably added to make it easier to
> transition from DTDs, as DTD allows attribute
> defaulting. Thank god Schema didn't port over general
> entities, though.
>
> There's a term to describe result of Schema validated
> document, with possible augmentations (PSVI,
> Post-Schema-Validation Infoset?).
>
>> 2.  it seems more like a way to modify the XML
>> structure.
>>
>> do you see this as an essential feature of XSD?
>
> Although I can't answer for Boris, I assume it all
> depends on use cases. For some use cases and users it
> may, for others not.
> But more than this, whether those use cases are core
> use cases for VTD.
>
> I have said this before, but I think there is value in
> knowing exactly where and to whom VTD could add most
> value. Whether it eventually gets used for wide-range
> of tasks or not, there are some areas where it seems
> more optimal than others. And from that one could ask
> the question: "does Schema in general matter for [core
> use cases]; and if it does, is attribute defaulting
> used for them".
>
> From my perspective, VTD's main potential benefit is
> its speed. But for many Schema-dependant use cases,
> users do not care (or are ignorant).
> I have seen enough developers write code where they
> convert from Strings to JDOM trees and back, happily
> using convenience methods to construct dynamic xpath
> expression all over the place, that I honestly do not
> think most developers care. Even by just properly
> using existing tools they'd get significant
> improvements.
> For them, it all comes down to perceived simplicity of
> API. Usually they are pretty happy when they see, say,
> XOM, after using DOM for a while.
>
> And then there are other use cases where performance
> does matter, and people are willing to invest time in
> understanding new tools and learning new APIs. That's
> where solutions like VTD may come in handy.
>
> -+ Tatu +-
>
>
>
>
>
________________________________________________________________________
____________
> Expecting? Get great news right away with email Auto-Check.
> Try the Yahoo! Mail Beta.
> http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html
> 

------------------------------------------------------------------------
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
V
_______________________________________________
Vtd-xml-users mailing list
Vtd...@li...
https://lists.sourceforge.net/lists/listinfo/vtd-xml-users

Hi Jimmy,

Jimmy Zhang <cra...@co...> writes:

> do you see this as an essential feature of XSD?

Looking at the wide use of default attribute values in public
schemas we can conclude that the users have decided it is an
essential feature ;-). I personally also think that it is a
handy feature (just as default argument values in modern
programming languages).

hth,
-boris

--=20
Boris Kolpackov
Code Synthesis Tools CC
http://www.codesynthesis.com
Open-Source, Cross-Platform C++ XML Data Binding

--- Boris Kolpackov <bo...@co...> wrote:

> Hi Jimmy,
> 
> Jimmy Zhang <cra...@co...> writes:
> 
> > do you see this as an essential feature of XSD?
> 
> Looking at the wide use of default attribute values
> in public
> schemas we can conclude that the users have decided
> it is an
> essential feature ;-). I personally also think that

Actually, I'm not sure that is conclusive proof --
what
matters more is how many actual document instances
make
use of such features.

However, it is interesting finding that so many
schemas
do make use of this feature. Personally I find it
depressing... since:

> it is a
> handy feature (just as default argument values in
> modern
> programming languages).

It may be just me, having to write parsers, but I
think
inclusion of attribute defaulting in XML Schema was
one
of its biggest blunders. It has nothing to do with
either
validation or data typing -- such business-logic
definitions
belong to another layer, not to static-by-nature
structural
(and coarse data typing) constraints model as schemas.

And as to programming languages, some have it (c++,
languages
with named parameters), others not (java, and most
scripting
langauges). I prefer not to have them, as kind of
syntactic
sugar I can live without; but at least it's less
fragile
as defaulting actual data in documents.

I can of course see practical convenience value, but I
would
lump it together with similar features like xml
general entities
or C preprocessor macros.

Anynway, to each his own,

-+ Tatu +-

____________________________________________________________________________________
Food fight? Enjoy some healthy debate 
in the Yahoo! Answers Food & Drink Q&A.
http://answers.yahoo.com/dir/?link=list&sid=396545367

Also, relying on schema to determine the value of  XML could cause
maintanence nightware down the road...

If the XML has to have some default value, why not just put it in XML?
To developers, there should be no surprises when processing the document...

----- Original Message ----- 
From: "Tatu Saloranta" <cow...@ya...>
To: "Boris Kolpackov" <bo...@co...>; "Jimmy Zhang" 
<cra...@co...>
Cc: <vtd...@li...>
Sent: Friday, January 26, 2007 9:22 PM
Subject: Re: [Vtd-xml-users] xerces discussion on VTD

> --- Boris Kolpackov <bo...@co...> wrote:
>
>> Hi Jimmy,
>>
>> Jimmy Zhang <cra...@co...> writes:
>>
>> > do you see this as an essential feature of XSD?
>>
>> Looking at the wide use of default attribute values
>> in public
>> schemas we can conclude that the users have decided
>> it is an
>> essential feature ;-). I personally also think that
>
> Actually, I'm not sure that is conclusive proof --
> what
> matters more is how many actual document instances
> make
> use of such features.
>
> However, it is interesting finding that so many
> schemas
> do make use of this feature. Personally I find it
> depressing... since:
>
>> it is a
>> handy feature (just as default argument values in
>> modern
>> programming languages).
>
> It may be just me, having to write parsers, but I
> think
> inclusion of attribute defaulting in XML Schema was
> one
> of its biggest blunders. It has nothing to do with
> either
> validation or data typing -- such business-logic
> definitions
> belong to another layer, not to static-by-nature
> structural
> (and coarse data typing) constraints model as schemas.
>
> And as to programming languages, some have it (c++,
> languages
> with named parameters), others not (java, and most
> scripting
> langauges). I prefer not to have them, as kind of
> syntactic
> sugar I can live without; but at least it's less
> fragile
> as defaulting actual data in documents.
>
> I can of course see practical convenience value, but I
> would
> lump it together with similar features like xml
> general entities
> or C preprocessor macros.
>
> Anynway, to each his own,
>
> -+ Tatu +-
>
>
>
>
> ____________________________________________________________________________________
> Food fight? Enjoy some healthy debate
> in the Yahoo! Answers Food & Drink Q&A.
> http://answers.yahoo.com/dir/?link=list&sid=396545367
> 

Jimmy Zhang wrote:
> Also, relying on schema to determine the value of  XML could cause
> maintanence nightware down the road...
> 
> If the XML has to have some default value, why not just put it in XML?
> To developers, there should be no surprises when processing the document...

Just my 2cents. I have noticed the same thing as Boris. Folks seem to 
like to use XML Schema default values. I think it's a popular convenience.

Cheers.

-- 
http://www.ScheduleWorld.com/
Free Google Calendar synchronization with Outlook, Evolution,
cell phones, BlackBerry, PalmOS, Exchange, Mozilla, Thunderbird,
Pocket PC/Windows Mobile. Also sync tasks, notes and contacts!
WebDAV, vfreebusy, RSS, LDAP, iCalendar, iTIP, iMIP support.

Sometimes it takes sometime for people to understand the implications
of the XSD features, it is just part of the evolution process. XML has
undergone the similar process before...
----- Original Message ----- 
From: "Mark Swanson" <ma...@Sc...>
To: <vtd...@li...>
Sent: Sunday, January 28, 2007 7:30 AM
Subject: Re: [Vtd-xml-users] xerces discussion on VTD

> Jimmy Zhang wrote:
>> Also, relying on schema to determine the value of  XML could cause
>> maintanence nightware down the road...
>>
>> If the XML has to have some default value, why not just put it in XML?
>> To developers, there should be no surprises when processing the 
>> document...
>
> Just my 2cents. I have noticed the same thing as Boris. Folks seem to
> like to use XML Schema default values. I think it's a popular convenience.
>
> Cheers.
>
> -- 
> http://www.ScheduleWorld.com/
> Free Google Calendar synchronization with Outlook, Evolution,
> cell phones, BlackBerry, PalmOS, Exchange, Mozilla, Thunderbird,
> Pocket PC/Windows Mobile. Also sync tasks, notes and contacts!
> WebDAV, vfreebusy, RSS, LDAP, iCalendar, iTIP, iMIP support.
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share 
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Vtd-xml-users mailing list
> Vtd...@li...
> https://lists.sourceforge.net/lists/listinfo/vtd-xml-users
> 

By essential I meant that, by taking it away, are there things 
that simply can't be done?

The fact is that after a standard gets accepted and used, it
takes a while for people to fully understand the strengthes/weaknesses
of it.

And the standards tend to evolve, shedding the parts that are less
useful or even harmful...

DTD is a good example, the external entity(which makes
XML complex to maintain and manage) is another ...

So at this point, I would not jump to the conclusion that this
is essential... I would rather keep an open mind on that...

Hi Jimmy,

Jimmy Zhang <cra...@co...> writes:

> do you see this as an essential feature of XSD?

Looking at the wide use of default attribute values in public
schemas we can conclude that the users have decided it is an
essential feature ;-). I personally also think that it is a
handy feature (just as default argument values in modern
programming languages).

hth,
-boris

-- 
Boris Kolpackov
Code Synthesis Tools CC
http://www.codesynthesis.com
Open-Source, Cross-Platform C++ XML Data Binding

----- Original Message ----- 
From: "Boris Kolpackov" <bo...@co...>
To: "Jimmy Zhang" <cra...@co...>
Cc: <vtd...@li...>
Sent: Tuesday, January 23, 2007 8:31 AM
Subject: Re: [Vtd-xml-users] xerces discussion on VTD