Cart
[Home] [By Thread] [By Date] [Recent Entries]
Paul Prescod <paul@p...> wrote: | Arjun Ray wrote: |> Paul Prescod <paul@p...> 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.
|
