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 Sun, Nov 11, 2001 at 11:11:43AM -0500, Gavin Thomas Nicol wrote:
> > 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.

  I had DocBook in mind when writing this section. Agreed it's 
based on the need to have DTDs and entities available locally and
somewhat special case. You're right let's stay focused.

> >   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
>    foo.xml?@id='bar'
> will point to all id attributes with the value 'bar', or something suchlike, 
> *in the context of your application*?

  Because of the IETF framework. The fragment identfier is the way web
aware application are supposed to found the expression of the sub resource
pointed to. From my point of view the Web framework is not something I would
go against. Also since 97 everybody expected to have foo#bar - when the
resource foo is delivered as an XML resource - to point to the element
carrying the ID "bar". Again breaking this expectation would be pretty major.

  So basically everybody expects in a Web aware XML processing environment to
have foo.xml#bar point to the element carrying ID "bar".

> >   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?

  Because it's what everybody expects :-)

> The only reason I've seen
>   foo.xml#bar
> proposed is for HTML compatability, and guess what, I've not seen much HTML 
> using that construct.

  Hum, you mean not using name="bar" or the alternative id="bar". We
seems to not browse the same web then :-)

> 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.

It's a special rule versus breaking the Web framework or/and an expected
processing people have taken for granted for years now.

  at least in my view...


Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/