zhouhui at wam.umd.edu
Wed Feb 2 06:32:31 PST 2005
Hopefully Jeremy doesn't mind I open a new thread with old topic :)
On Tue, Feb 01, 2005 at 10:54:28PM -0700, Kevin P. Fleming wrote:
>Hui Zhou wrote:
>>As I tried to express, even with XML, it can be extremely simple
>>can comeup with a parser overnight without dependency or it can be
>>complicated enought for me to spend weeks to study the w3c spec. Its
>>like it ranges from scooter to full size hummer. The hummer comes
>>higher maintainence albeit brings extra whistles. My philosophy is
>>stay simple and know what I need.
>Will your simple parser handle:
Thanks, Kevin, I love detailed discussion.
>- XIncludes, or some other means of building a combined profile from
>lots of little pieces
I would say it suffices to restrict individual piece to be a package.
Check out my old profile:
lfs is treated as a package, which include subpackage ch5_pre, ch5,
ch6_pre, ch6 and ch6_post, each inturn may have subpackages. My parser
or tool seraches the package name inside its inventory, if not found,
look for individual profile within a directory hierarchy.
So I have the freedom either use a whold profile for all the
packages, or optionally make it little pieces with each piece
essentially a root node within the top package.
So the answer is yes.
And It not necessary has to be myway, there are many other
intuitive, easy way without learning this:
which is another 30 pages!
>- character encoding, to allow the user to be able to put entity
>into their profile using their native language/encodings
Do we really have the urge to support - say Chinese (my first
language) -? If there is, that can be added in. That is just simply
increase the profiles character set, in most case, trivia.
However, I seriously doubt the need.
>- validation to ensure that already-known required elements are
>(for example, a [copy] element missing a [source] or a [destination])
I shouted several times that validation is unnecessary. Thanks for the
example, I will explain.
After parsing, or during parsing, the tool will barf on
missing source or destination under copy. He does not need a dtd to
tell him, because without source or destination, he wouldn't know how
to do it; even say, the dtd (faulty maybe) says its validate, the tool
will barf because it doesn't make sense.
And for example, the tool takes defaults, the tool work
happily with the copy on missing destination if a default destination
available, there is nothing wrong there.
Missing destination under copy is not a very common mistake a
profile writer will make, make typos in the destination is common.
Validation won't help you here.
It is quite arguable do we need split a simple "cp src dst"
into three entities and make the profile worry about 6 tags including
3 matching '/'s.
I implemented my tool in less time that I was able to learn DTD.
>- additional attributes added by the user for their own needs, but
>ignored by the alfs tool
Do you mean will my parser or tool ignore those extra attributes
I don't use attributes. Attibutes are implemented as subnodes
under the parent nodes. I find it suffice.
Yes, my tool lives happily with extra tags he doesn't understand
as long as they don't hurt (no, they do not).
>All of these already part of standard XML (with the addition of
>XIncludes), and handled correctly by every compliant XML parser.
>are also things that we know we already need, because we have been
>them and they have been beneficial. While the profiles could
>be built without them, there are good reasons to continue using these
Beneficial? I had quite some pains on editing the profiles 2 years
back. I have the same problem as Gerard that we don't generally want
to follow the book.
Good reasons? May I hear more? in specific detail.
More information about the alfs-discuss