Cart
[Home] [By Thread] [By Date] [Recent Entries]
Hi Liam,
Thank you for your interesting response. I agree with you that, as I noted also, namespaces take some getting use to, and typos can be ... surprising. Let's also be clear that I have no document with 80 or so namespaces, only stylesheets that deal with a lot of different document types. As for translating dictionaries, what I tried to point out was not that there was a syntactic link between namespaces and content languages, only that conceptually natural languages, for example, were "conceptual" namespaces, implying, or trying to imply that they may be a natural match for (XML) namespaces, in a translation dictionary context. Yes I can create a dictionary like <dic> <word> <instance xml:lang="en" gender="m">Mr</instance> <instance xml:lang="en" gender="f">Mrs</instance> <instance xml:lang="fr" gender="m">M.</instance> <instance xml:lang="fr" gender="f">Mme</instance> ... </word> </dic> but, given the proper namespace declarations, I could also have it as <dic> <word en:instance="Mr" en-f:instance="Mrs" fr:instance="M." fr-f:instance="Mme" ... /> ... </dic> in both cases, source documents are using xml:lang to determine what to pick, but: 1. while the second version could use en, en-f, fr, fr-f for values, the first would either require a second attribute for gender or a piece of code to split the xml:lang attribute, to match two attributes instead of a namespace 2. in the first version, the example entry uses 17 nodes while the second version uses 5, and more languages would increase the difference 3. as you point out, namespaces are syntactic constructs, that probably get resolved at compile time, rather than run time Which brings up the question that the first version is trying to get around using namespaces for something that is conceptually namespace-based, with some real physical, transformational, and design costs. I did not want to get into the discrepancies of RDF, but just tried pointing out that stylesheets and transformation pipelines may have to deal with multiple document types, with the associated namespaces. OTOH, I have been thinking and addressing the RDF discrepancies and would go beyond what you suggest, but it may be more appropriate to take this off-list, if you care. Having been using 80 namespaces in a stylesheet, I quite realize that there are no "8 namespaces" limit. It was Andrew, and Gerrit indirectly, that suggested that 8 namespaces could be a reasonable maximum for a stylesheet. As well, both Michael and Gerrit pointed out that a binary search may prove more efficient for managing namespaces, beyond that "reasonable" maximum. I question the reasonableness of the suggested maximum and feel that indeed, a binary namespace search would be a useful feature. As for namespace-based specific knowledge domain transformations, one may have, for example, many attributes and elements, in transformation pipeline streams, for example, that hold, let's say GML content that may require typical parsing or transformation of some sort. So either each transformation stylesheets has to know and match all possible attribute and element names that may contain such data, or all these attributes and elements are put in a common namespace and a template simply matches the namespace, to processes all possible related items. Designwise, I much prefer the latter, even if it implies defining a namespace for time intervals and another for space intervals, and another for ... As you suggest, one could also put all the target items into sub element under some convention and systematically impose that convention, somewhat like: <timeinterval> <morning>...</morning> <after-noon>...</after-noon> </timeinterval> knowing that every element under <timeinterval> should be processed according to time interval transformations (e.g. <xsl:apply-templates select="timeinterval/*" mode="timeinterval"/>) but, as this involves more nodes, less flexibility, and more processing, again, it feels like a workaround and patch for not using namespaces, when namespaces fit naturally, more efficiently, and more simply. As for remembering the namespaces and prefixes, I would recommend: 1. define only required namespaces 2. define namespaces and prefixes carefully 3. break large stylesheets into smaller ones, typically around the namespaces and associated application domains 4. look at the top of the stylesheet to find (and define) namespaces and their prefixes 5. its mostly the stylesheets, the stylesheet documentation, the stylesheet authors, and the individual domain document authors that need to remember the namespaces that each is working with This is still better than having to remember the dummy elements that would have to be added otherwise, apart from the additional associated document and transformation overhead. These special items would also not be formally declared at the top of the stylesheets, making redundent documentation a requirement. Note also that typos on the marking elements could also create issues. Again, those RDF issues, especially for semantic relevance and coherence, have been resolved with much better grounded foundations, and I would be happy to discuss and present on this, in a more appropriate context. Regards, Andre On Sun, 2011-04-17 at 19:30 -0400, ac wrote:
|
