[
Lists Home |
Date Index |
Thread Index
]
Paul Prescod <paul@prescod.net> wrote:
| Arjun Ray wrote:
|> Paul Prescod <paul@prescod.net> wrote:
|>| Any rule that handled the book/html case would fall apart in the face
|>| of XSLT/XSLFO.
|>
|> The general problem is the same.
|
| Not really.
Yes really.
| One is a code/literal problem. The other is a "reuse these semantics"
| problem.
What is this "reuse these semantics" problem? Once again, this is not
about what names could mean.
| They are quite different which is why there is no general semantics
| for embedding namespaces.
The notion that XSLT "needs" namespaces is the same delusion.
| [XSLT, WSDL, RDF etc] ascribe their own semantics to the syntactic
| convention of "foreign namespaces".
That is precisely what I mean by DWIMming: you are setting "rules" for
"others", not just for "yourself".
| If BookML were formally defined then the formal definition should tell
| you how to handle PCDATA in the extraction of the implicit XHTML
| document.
Yes, we know this. That's how classical AFs work, for example (using a
validation schema to drive parsing). But once again, I'm not concerned
with schema-driven parsing. I'm concerned with markup to isolate that
which could be validated if someone wanted (but validation is *not*
necessarily the purpose of the discrimination achieved by parsing.)
| But the simple answer is you cannot tell how to segment namespaced
| fragments just by relying on the semantics defined in the Namespaces
| specification.
Correct. The spec is silent on this, and thus useless for the general
problem of vocabulary combination *by syntax*.
| You must also rely on the rule defined by your vocabulary.
Nope. That's a myth too.
|
