[
Lists Home |
Date Index |
Thread Index
]
Amelia A Lewis wrote:
>>i don't know sax too well, but shouldn't there already exist such a case
>>for 'attributes' and 'namespace attributes' of an element, so that when
>>an attribute declaring a namespace is being parsed, two events could be
>>raised? how does handle sax this?
> A namespace declaration is not an attribute (even if DOM treats it like
> one).
it sure is. that's what xml 1.0 tells me, and xml 1.0 is always right!
it is an attribute with additional semantics, in the same way as an
xlink:type="extended" element is an element with additional semantics.
>>and yes, introducing infoset extensibility certainly would make any api
>>more complex, even though i think that the issues that were being raised
>>could be solved. and: if you didn't need or want access to the infoset
>>extensions, than you could still use a good old sax1/2 parser.
> I don't believe that I made my point sufficiently clearly. I think that
> the infoset was designed to provide a full representation of the
> interesting information in an XML instance. Therefore, any additional
> processing (such as the PSVI or the mooted XLink information items)
> should be processed in a *different* layer. Polluting the infoset is
> not acceptable. Adding a layer may be okay.
but for example namespaces already are such a layer, and most people
probably agree that it is good to have such a layer uniformly and not
require everyone who is interested in namespaces having build their own
one. in the same way i propose a layer for linking, and if you are not
interested in linking, then you don't use it. but if you are, you will
be happy to have the layer uniformly provided across different products
and specifications.
> Keep in mind that once you add the layers, you immediately encounter a
> problem of ordering. Does schema validation happen before, or after
> link information enhancement? Note that the XQuery/XPath folks have
> encountered this problem, and have declared that the XPath datamodel is
> a transformation of the post-schema-validation infoset, which is itself
> (in their discussion, last I checked) an enhancing transformation of the
> infoset. The infoset is left alone; order of processing is defined (but
> note that this doesn't leave much room to add enhancements in different
> directions, such as XLink).
i agree that things get more complicated. but they always do if you add
semantics. the xlink "layer" would be added after core infoset and psvi
processing (if there is an xml schema for the document), and it would
require additional semantic checks (all the validity constraints that
xlink defines). but if you want to work with xlink, you have to do these
checks anyway, so you might as well shift the burden from each user to a
standardized way of processing xlink information.
> The alternative, pushing the information items down into the infoset
> itself, doesn't change the problem, it merely makes use of the infoset
> as problematic as use of layers on top of the infoset currently is.
i don't want to "push down" anything. i want to extend the infoset in a
modular way, and if you are not interested in my module, you don't have
to use it or even know about it.
cheers,
erik wilde - tel:+41-1-6325132 - fax:+41-1-6321035
mailto:net.dret@dret.net - http://dret.net/
computer engineering and networks laboratory
swiss federal institute of technology (eth)
* try not. do, or do not. there is no try. *
|
