OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: comments from doug bunting on v0.98b


> I have no heartburn about adding an id attribute to all top-level
> elements so that they can be easily (cross-)referenced. Having the id
> element on the Manifest makes it easy to reference from a dsig:Reference
> (you can have the URI be an IDREF fro simplicity)

I'd like to see ID allowed on the top-level elements for just this
reason.  (I thought this was already specified by the XML spec, but I
just looked back and I must have been confused.)  There are probably
some lower-level elements (individual error or trace entries?), but I
don't think they're really needed for 1.0.  Perhaps a note saying "in
the future, everyone could have an ID"?

> I am not clear as to your point that we don't use id attributes
> consistently, unless you mean "we don't provide for an optional 'id'
> attribute on significant elements in our schema", in which case I agree.

Perhaps it's that some elements used their own name for an id, rather
than just "ID"?  (I seem to recall that this was more of an issue in
areas like the CPP/CPA, where things like "certID" appear)

> I'll go with a majority opinion on this. Adding an id attribute is
> no big deal unless we go to the extreem that it is required on
> all elements for which we provide it, which would make the spec
> a little more complicated than it needs to be.

If XSD supported multiple inheritance ... :)
	/r$


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC