Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] getElementById (not again.... I know, but..)

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Tatu Saloranta <cowtowncoder AT yahoo.com>
  • To: xom-interest <xom-interest AT lists.ibiblio.org>
  • Subject: Re: [XOM-interest] getElementById (not again.... I know, but..)
  • Date: Sun, 8 Oct 2006 21:29:16 -0700 (PDT)

--- Elliotte Harold <elharo AT metalab.unc.edu> wrote:

> John Cowan wrote:
>
> > No, it isn't. An attribute is of type ID if and
> > only if one or more of the following is true:
...

This is my understanding as well (with addition of
RelaxNG schema info).

...
> I don't think it's that clear in practice. For
> example, if you're
> parsing well-formed HTML there's a user expectation
> that all attributes
> named id, ID, Id, or iD are treated as IDs.

Maybe, but XOM is not an HTML tree model (unlike DOM),
but an XML tree model. So should this not be out of
scope for XOM?

In case where one uses nice conversion tools to get
from HTML to XML, like, say, TagSoup, underlying
parser
could do per-format heuristics like assuming all
'id' attributes have this semantic (and/or
auto-attaching
basic HTML DTD)?

> If you're using XPath on a DTDless document then
> elements declared as
> xs:ID in a W3C schema do not have type ID, and
> arguably xml:id elements
> don't either (unless declared that way in a DTD).

If the parser supports Xml:id specification, they
should, though. This seems to be the main purpose
of Xml:id specification.

> And what about ID-type attribute declared in a RELAX
> NG schema?

That should likewise be included, but as with other
methods, I wouldn't expect XOM to be concerned with
this, but the underlying parser.

> Like a lot of other things, "IDness" is in the eye
> of the beholder. It's
> a really nasty rabbit-hole that I've been sucked
> down more than once;
> and I'd like to avoid going there again if I can
> help it.

I can see this as being potentially confusing, in
regards to implied DOM compatibility (if using
same method name). However, perhaps this would
be less of an issue if it was clearly documented
to be based on standard XML Infoset information,
as provided by the underlying parser, and nothing
else? I am not sure I fully understand the concerns,
outside of using XML processing tools with HTML.

In the end, perhaps it might be good to just document
this as an FAQ,

-+ Tatu +-


__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com




Archive powered by MHonArc 2.6.24.

Top of Page