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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xml-dev] So maybe ID isn't a problem after all.

On Sunday 11 November 2001 05:01 am, Daniel Veillard wrote:
> On Sun, Nov 11, 2001 at 01:19:21AM -0500, Gavin Thomas Nicol wrote:
> > People understood XML pretty well.
> Hum, coming from basically 2 years of work educating the Gnome project
> developpers to use XML, they are making real use of it, but certainly
> not specialist in markup languages.
>   If you limit it to:
>     - well formedness
>     - just ascii
>     - strip "formatting blanks"
> then this is is true.

OK. I probably overstated the ease-of-use thing, but I was pretty much just 
thinking of elements, attributes, and text.  My experience is that users, 
*not* developers,  can grok things at that level pretty easily.

> I don't think xml:base is any more complex than understanding encoding
> support, or xml:space. 

Well, I think xml:space is another misguided attempt, so cheerfully ignore it 
and recommend that other do the same. As for encoding support... only those 
who have a need have to learn about it.

> On the other hand properly setting the DOCTYPE and having working
> Catalogs (SGML or XML) is still black magic for a number of
> users of XML (i.e. not designers). And this is the basic building
> blocks needed to have a working framework in practice.

I don't think you need these in order to use XML effectively. In some cases, 
yes, in most, no.

>   If you put xml:id="foo" on an element then blah.xml#foo will point to it
> is relatively clear and simple. On the other hand

Why special case it though? The main thing ID's buy you is a guarantee that a 
validating parser is going to ensure the values are unique. How about 
ignoring all the DTD and XML special treatment and simply say that


will point to all id attributes with the value 'bar', or something suchlike, 
*in the context of your application*?

>   I think the first case gives them 80% of their pointing needs. I won't
> suggest they use anything like this for existing DTD like DocBook we use
> for documentation where DTD processing is basically mandatory, but for
> all the simple uses like small data storage (configuration files,
> speadsheet format, etc...) it just fits the bill. Most of those simple
> cases don't even have a DTD defined for them.

Sure, so if they don't have a DTD, why are we pushing something that has 
meaning only in that context? The only reason I've seen


proposed is for HTML compatability, and guess what, I've not seen much HTML 
using that construct. Why not put in place a more generic, and just as simple 
solution? AT least people wouldn't have to learn special rules, and remember 
when they apply and when they don't.