OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: DOCBOOK: Re: XML Schemas and docbook documents

On Mon, Dec 10, 2001 at 09:18:23AM -0500, Norman Walsh wrote:
> / Yann Dirson <ydirson@fr.alcove.com> was heard to say:
> | In other words, I was thinking of extending the syntax of attributes
> | so that we could write:
> | 
> | <article
> |   <class>whitepaper</>
> I've seen this suggested elsewhere recently. Specifically, that we could introduce
> a new syntax using some prefix character for "attribute elements". That you'd make
>   <article class="whitepaper">
> the same as
>   <article>
>     <_class>whitepaper</_class>
> (If you selected "_" as the prefix character.)

> While this would solve the problem from a purely pragmatic point of
> view, I'm not sure I like what it does to the XML data model and the
> complexity of applications.

Hm... this may address the problem at hand, but not the "stripping the
tags should only give the text" issue.  OTOH, it gives some sort of
backward compatibility, but I'm not completely at ease here.

It really push further the confusion between attributes and
sub-elements, which usually do not matter much for data-structuring
application (which are a more and more common use of XML).  In those
applications, people have traditionally used elements because the
syntax of attributes was not adequate.

IMHO that, once more, clearly shows that text-processing and
data-processing have different needs.  We, for text-processing, have a
need for putting all meta-info inside tags ; OTOH, for
data-processing, they usually do not have the notion of text, and they
are heading in a different direction, which makes they usually have no
need for a distinction bewteen elements and attributes.

That will probably result in XML continuing to evolve in a
data-centric direction, whereas we will still need the
element/attribute concept.

Ideally, I think we would need to have a core of technologies,
suitable both for text and data processing, and specific ones for each
of the two.

> | But maybe there is a fundamental problem here, in that something that
> | isn't really an attribute should not use attribute syntax...
> Yeah, I would have preferred processing instructions to magic
> attributes, but that's not the way the Namespaces Recommendation
> turned out.

Hm... why are there so many decisions in all those XML-related
technologies that make me more and more reluctant to move to them ?

Yann Dirson <Yann.Dirson@fr.alcove.com>                 http://www.alcove.com/
Free-Software Engineer				      Ingénieur Logiciel-Libre
Free-Software time manager    	       Responsable du temps Informatique-Libre
Debian GNU/Linux developper <dirson@debian.org>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC