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: SAX 2.0 enhancement proposal



/ David Brownell <david-b@pacbell.net> was heard to say:
| > > I always took that "unless" clause to apply to relative URIs showing
| > > up somewhere in document content, not in the DTD; all those examples
| > > were of that type, and the rest of that sentence (and paragraph, and
| > > section!) clearly applies to URIs as declared within the DTD, not to
| > > any of the cases in that clause's examples.
| > 
| > I took it to apply to both.  It would be peculiar to embed the
| > statement in a paragraph about system identifiers if it didn't apply
| > to them.
| 
| That clause was indeed rather peculiar.  At best it was an incomplete
| thought; the spec has no business leaving the door open to retrospective
| re-interpretation of data that's already been parsed/interpreted.

I think the open question is whether or not a system identifier
{can|must|should|may|must not} be made absolute the instant that it's
returned by the tokenizer. I don't think the spec is clear on that
point.

| > I assume by "those examples" you mean "a special XML element type
| > defined by a particular DTD, or ...
| 
| That in particular was bizarre, yes.  <xhtml:base> (or xml:base attributes)
| would be in the body of the document, so why the heck would they even
| need to be mentioned in a section talking about the DTD?  The same is
| true for _any_ application level semantics (such as PIs).

There's absolutely nothing wrong with PIs in the internal or external
subset to provide semantics. They're every bit as valid and reasonable
(though perhaps not as interoperable) as declarations.

                                        Be seeing you,
                                          norm

-- 
Norman.Walsh@Sun.COM   | To create a little flower is the labour of
XML Standards Engineer | ages.--Blake
Technology Dev. Group  | 
Sun Microsystems, Inc. |