[
Lists Home |
Date Index |
Thread Index
]
Arjun Ray wrote:
> "J.Pietschmann" <j3322ptm@yahoo.de> wrote:
> | Arjun Ray wrote:
>
> |> I sense a prejudice that processing DTDs is inherently "difficult"
> |> (and thus something it might be useful to, um, "optimize away".)
> |
> | Whether it is difficult or not, it takes processing time and other
> | ressources.
>
> I'd love to hear about that magical formalism for declarative information
> which doesn't take processing time and resources.
Umm, I don't think I implied the existence of such a formalism.
I was under the impression that the "no-DTD" discussion
revolves around the redundancy of *any* such formalism in certain
(not all) situations.
> I suppose at some point the reason will have to be rediscovered why system
> identifiers in notation declarations - in SGML, at least - often point to
> executable code. (And, yes, XML has butchered this one.)
I'm not sure how Linux-OS/390 executable code is going to help
me on my Win2k machine. I'm pretty sure the mechanisms
provided by SGML did work well in the environment of editing
and processing SGML documents in a controlled environment, but
we are talking about sending data over networks to clients
outside the enterprise and similar stuff.
> | From an XSLT perspective, XInclude is much better than entities.
>
> Actually, there is no difference. CONREF attributes needed reinvention,
> after all.
Entities have to be resolved by the parser, there is no way
to pass them downstream because there are no entities in the
logical data model. An XSLT processor is never goint to see
any entities from an upstream processing unit. Likewise, an
XSLT processor can't produce entity definitions nor references
to pass them downstream. XInclude elements can be created,
and, provided it is accepted as an standard passed to an XSLT
processor. I don't see what this has to do with CONREF
attributes.
Regarding CONREF: XML is no longer about single logical
documents, perhaps split into several physical documents,
but still processed as a whole. There is a possiblity that
someone wants to XInlude the result of a web service call,
looking up the name of a city from a ZIP code. The web
service has an URL, not an ID.
> | I need names which are unique over a *set* of documents. IDs are not
> | sufficient for this.
>
> They aren't even relevant to this. They serve a different purpose. (In
> general, if you've never seen the need for IDREF attributes, then you've
> probably never needed ID attributes. A wholesale importation of DB-think
> is a surefire way to go wrong here.)
I had started with IDs and IDREFs. IDs are great as long as you
have one logical document, and you use entities for physically
splitting it.
I used XML for describing interfaces. There are several hundred
interface thingies for a total 1.5MB of data. Putting this into
one file is too much for the XML editors I used. Putting every
thingy into it's own file was not a real solution either: changing
the master file with the entity declarations in the internal subset
and the references in the body is more bothersome than i like, apart
from the problems with the XML editor and various tools who didn't
like this approach very much. Also, because the thingies were edited
independently now, allocating IDs became a growing nightmare.
Moreover, there were requirements to specifiy some thingies and
produce a file with them and all thingies they depend on. Creating
this by hand is painful.
The whole problem disappeard after I switched to my own reference
elements and used XSLT, in particular document(), for doing the merge.
After this, I soon realized that xsl:key is much more powerful and
flexible than IDs.
With XSLT at the core of the toolset, the need for IDs and entities
disappears.
|
