[
Lists Home |
Date Index |
Thread Index
]
On Sun, Dec 15, 2002 at 09:14:50PM -0500, Simon St.Laurent wrote:
> I'm not entirely sure from reading the draft what it is that you're
> proposing or that a media type (as opposed to a media feature[1], for
> instance) is the right way to go about it. My summary of the document
> would suggest that content of type application/xmld should be processed
> on a namespace-URIs-first basis, but it's not clear to me what
> (especially in the absence of a schema or perhaps better a RDDL
> document) should be done when unknown namespaces are encountered.
Well, that's a large part of what the draft is about, though I know
it's still far from complete. Also, for several reasons, I want to
avoid having to look up schema or similar; one big one being that a
document should have a standalone meaning, even if you don't know how
to extract all of it.
> I think that document is an interesting start, but it's not clear to me
> that "dispatch" is the right paradigm for namespace-based processing.
> Dispatch makes sense in the context of, say, an XHTML document with
> embedded XForms and SVG and using plug-in-like mechanisms for the
> handling. I'm not sure it makes the same kind of sense as a general
> approach to handling namespaces and XML - but I'll confess that I'm not
> sure what a general approach might look like.
I think it's fairly general (well, if it were complete 8-), but not
completely so. Like I said, I was *aiming* for an 80/20 solution.
> <record xmlns="http://simonstl.com/ns/record";
> xmlns:str="http://www.w3.org/TR/xmlschema-2/#string";
> xmlns:date="http://www.w3.org/TR/xmlschema-2/#date";
> xmlns:int="http://www.w3.org/TR/xmlschema-2/#int";
> >
> <str:firstName>Simon</str:firstName>
> <date:birthdate>1970-11-25</date:birthdate>
> <int:age>32</int:age>
> </record>
>
> In this case, the "collection of names" is a collection of names that
> happen to contain strings, dates, or integers, not a collection that
> was precisely connected to a vocabulary.
Right, which is why I consider that broken. I haven't seen it before
anyhow, so I don't know that it's worth considering for an 80/20
solution.
> Also, local names have real power - href and id are two very common
> local names used in multiple namespaces, for instance. (You acknowledge
> that in the draft.) There are real cases where that local name may in
> fact be more important to processing (link and bastardized ID hunting)
> than the namespace that happens to be applied to it. This kind of
> thing keeps coming up in various contexts, and I doubt it will
> disappear soon.
Hmm. I'd have to think about it.
> I wish I saw a simple 80/20 here, but I really don't, especially if
> elements using unknown "visiting" namespaces contain content in "known"
> namespaces.
That case depends on two things; what it means to each namespace, that
another namespace is contained within the given elements.
The former is a known quantity, because its the known namespace. The
latter, without any indication to the contrary, should mean that portion
of the document is not processable (which may be ok, depending upon the
semantics of the innermost container of the known namespace). By
"indication", I mean that the producer of the compound document could
provide hints to aid in partial processing. A mandatory extension
declaration would be one kind of hint. But another may be an indication
of the type of container, such as if it's a sequence, a set of
alternatives, a bag, etc.. (like rdf:Container). Perhaps that might be
helpful in processing it, not sure. Haven't really thought that
through, though I probably should if it's gonna be 80/20.
> [1] - http://simonstl.com/ietf/draft-stlaurent-feature-xmlns-03.txt is a
> media feature which identifies the namespaces used in a document rather
> than specifying their processing, but a media feature saying something
> like "this document expects namespace dispatching" might make sense and
> be easily integrated with a wide variety of +xml types.
Yes, I should have considered that option in the binding section. But I
feel that a new media type is still the best way to go, at least at this
point in time.
If enough people feel this is important, I'd be happy to work on this
again. My hunch is that there *is* an 80/20 solution here, but it ain't
gonna be easy.
MB
--
Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis
|
